12/28/2011 ~ 5 min read

Things I have Learned In 10+ Years Of Work (Working Title)


http://www.inc.com/jeff-haden/the-5-qualities-of-remarkable-bosses.html 5. Learn where the action is. I find out so much when I visit one of my clients in their office. Is the lobby bright and inviting with recent accolades proudly displayed? Do employees seem happy? Is there free juice and healthy snacks in the cafeteria? Brand new Herman Miller chairs in the conference room? Is everyone moving in slow motion or is there a palpable buzz? The environment speaks volumes and may factor into your business proposal or plan. By understanding company dynamics, we can communicate more effectively to meet their needs. In my current role, I have been working on the application for almost a year now and I noticed that one section I keep returning to has multiple, multiple layers of nested if/then blocks (There were five layers). I noticed that the first two if statements could be combined into one check and a function call that returned a t/f value and then you could also stream line nested logic so that it wasn’t as branchy. Is branchy even a word? When I talked to the developer who wrote it and showed him how I wanted to rewrite it he became a bit defensive and said that the best thing to do was to just leave it since it worked. The thing is, I have a hard time remembering or tracing this particular area in the code. The variable names are not intuitive, the logic makes sense when I ask the developer why a certain line is there or what it is doing but in this particular area of the application there is a lot going on so there are numerous entry points to this area. I usually end up in this part of the code with some questions for the original developer. Now, my question is related to the fact that I am friends with the developer outside of the day job, in fact he is the one who recommended me for my current job and is a Senior Systems Architect here. I had worked with him before when I was just transitioning from my first career (see below) into web development and I looked up to him as a senior developer then too. In this current company, much of the code base was written by him and I see alot of other things like this, things I would call spagetti logic (It makes sense to the developer doing a first iteration on a problem but that understanding is locked away from me). I am starting to think that instead of asking to change something in order to make it simpler and easy to use I should change it and document the change with what/why/when. As a side note, there is very little documentation in the system - alot of functions are documented like “A little ditty that does blah for the Model attribute because it is a business requirement.” or “addblahAction adds a blah screen. Driven by addmodelAction”). However, the more I get into my friends codebase at this company, the less I think of his programming/system architecture skills. His code works, it gets the job done for the most part but it is hard to work on and he is very resistent to any modifications or re-factoring. So I am left wondering if it is me that is not getting something. Almost everything we do (I have also seen this at a few other small companies where I worked in web development. They are not quite start ups because they are several years old and have some sort of a profitable business model out of doing website/application development that pays the bills, at least for now.) is in contrary to what I learned when I went back to school for CS. My take away from school was that linux and emacs are a good fit for my mind and that the web is a really cool virtual place where you can easily make billions. 2/3 is good for me. I also remember at least at my school, there was a large emphasis on thinking about the problem you are trying to solve and then submitting your solution. This seems in contrary with what I find in the small web shop type companies I have experience with in my area. I find the approach is much the opposite - implement bug fix or feature request as fast as possible and just get it to work and client signs off on it. Leave that code alone unless we are absolutely required to change it and then only change it enough not to break anything and resolve the issue at hand. I have two questions. When did you know that you should just start making changes to a code base without explicitly getting approval from senior team members? Have you ever been in a situation where you thought the people you were learning from are really nice people but may not be guiding you with the best programming/development advice (not maliciously, just because they were never taught better or thats the way they learned or insert any number of benign reasons here); what did you do?


Headshot of Matthew Hippely

Hi, I’m Matthew. I live in Ventura County, and spend my time thinking about systems, software, and how things evolve over time.

You can find me on GitHub, LinkedIn, or read more about me here.