Coding Alone In The Dark

“Code Smell” is an expression given when glancing at some code and seeing right away potential issues with the way it is designed. Martin Fowler describes it as “a surface indication that usually corresponds to a deeper problem in the system”. It is often tied with the notions of pasted code, anti patterns, over complexity, etc. I personally like the image of the expression: One barely needs to look at the code to know that there might be something wrong with it. Today, there are hundreds of articles that talk about how to detect code smells. There are tools that spit out metrics letting you know what could be improved. You get the idea…

Today I want to talk about another type of code smell : code that has been entirely designed and produced by a single person, code which has never been seen or reviewed by others peers, code that has been produced in the dark is almost always a code smell. (By definition, this excludes anything that is open source). This doesn’t mean that it is bad code, but most likely that it can be improved and perfected if viewed by and discussed with others. Even though there may be some exception to the rule, I have personnally never seen this theory fail once in all my years as a software developer. If you are doing it alone, you are doing it wrong. 

When you are aware that your code will not be seen by others, it takes an extreme amount of self discipline to not take shortcuts. Documentation will be sparse, routines will not be optimized, refactoring might not be complete. You might produce code that works, but if you honestly ask yourself the question: “is there anything I would change if my code was to be open sourced to thousands of developers tomorrow?”, chances are you will come up with a bunch of TODOs.

On the other end, coding “in the light” of others only brings positive things. You will be more careful when writing for others than for yourself. You will worry more about small details, such as the way you name your variables. You will make sure that your logic and algorithm are implemented and tested correctly. Your code will be easily readable by anyone. And once your code is out in the open for others to analyze, it will only improve with time. The feedback from others will make you a more humble and a greater coder. This is, I believe, the true gold that is provided by open source development.

At most private companies, designing the code for a feature usually involves multiple people. Code reviews are done prior to features being tested. Everyone knows the ROI of taking that extra step. Yet every so often, because of time concerns, of pride, or even worse because of fear of appearing dumb, code falls through the cracks, burns bridges and ends up being shipped in your software without having been looked at.

While I’ve had many occasions to avoid putting my code in the light, I found that I never had a good, solid reason to do so. Lack of time? Fear of what other devs might say? Lazyness? Pride? I’ve personnally gone through all these feelings many times. Asking for and accepting feedback is not easy. It hurts to realize that what you found great, others found perfectible. It sucks to realize that you have to spend more time refining code you thought complete. Noone likes to be told that he is wrong. Especially not coders, where personal pride and self justification too often come in the way of building greater code.

You’re probably thinking: “well yeah, you’re just stating the obvious: code reviews improve code quality… yadi yada.” Yes, it is obvious. But it’s not a natural thing for developers to do! We coders are mostly cavemen. We like the comfort of privacy, we need to experiment and create on our own. It is not a natural thing to bring our code in the light. I have heard and seen so many times developers who were left alone to create and publish code, in the name of trust and autonomy, only to realize too late that what they had created was awkward, unstable and prone to WTF moments. Just a few weeks ago, I stumbled upon a database schema that had been created by a mercenary who had only stayed a few months at our company. It contained a bunch of 3-letter tables with each 20-30 columns that had 3-letter names… No-one had a clue of which column stored what. The developer had been left alone for 6 months because of his seniority status. He only left behind mysterious, unoptimized and non logical code. Was it his fault for not showing his code to others? The peers’ fault for not asking? When a team cannot work together to produce high-quality code, it’s more a team issue than an individual fault. Coders shouldn’t feel forced to share their code. They should do it out of desire, because they realize the outstanding positive impact that it can have on his/her own coding skills and on the code itself. 

Don’t code alone in the dark. Talk about your code, write about your code. Share it, ask your peers to look at it, to discuss it, to criticize it. Get everyone involved in the process. A junior developer will build confidence when trusted with the opportunity to criticize code produced by his older peers. He will learn from analyzing good code. A senior i’ve-seen-it-all developer has the ability to look at the problem with a renewed eye and can be a trumendous asset. When given the opportunity, take the time to review your peer’s code. Learn from it. Find what could be done better. Outline the great things that you see, discuss the issues that you find and give constructive feedbacks. 

Beautiful code never comes out of the dark, it is always refined through the fire of analysis and criticism.

[edit] : I received a lot of comments on reddit / codeproject about things which weren’t understood the way I intended them to be. I am not meaning to say that code produced by a single person is bad code or “smells”. I am using the terms “doing it wrong” because there is so much more to gain from working on code as a group of individuals than as a solo dev. I have modified the article to reflect that.

17 thoughts on “Coding Alone In The Dark

  1. It’s scary how true this is.

    When we code together with our peers/colleagues/coworkers/whatever, we’re under constant pressure to keep our code clean, whether we realize it or not. Once we’re left alone, our exploratory instinct kicks in, and we start playing with code, neglecting quality for quick solutions, so that we can get to the next challenge, and so on.

    I think this is the reason why pair programming is trending right now, and why most coders ‘feel’ they’re more productive in such environments.

  2. Being the only programmer in the company doesn’t leaves much choice but code “in the dark”. On the other hand — being the only one also means that I’ll have to maintain my own code, even 10+ years after it first saw the light of the day. And that’s not possible without taking really good care of the code.
    Besides, as a bonus I get to see how much I improved during the years as I, almost, always sees a better way to accomplish nowadays.

    Sincerely /Jonas

    • Hey Jonas!

      Having worked for a tiny company at one point, I completely understand your case. And I think that it’s great that you are taking care of your code knowing that you will be the one maintaining it later. However there is so much benefit to being able to share your code with others. Would your company agree to open source some of the things that you code? Do you still find time to work on some collaborative or open source projects on your spare time? I can really tell you from experience that it will be a trumendous gain for you as a coder.

      Good luck, and thanks for reading! 🙂

  3. You are NOT your code!!!

    Most of us try to do the best we can out of a sense of pride but due to the time and financial constraints of the real world this is sometimes not possible, especially in smaller companies.

    Does this lead to technical debt? Absolutely, but sometimes this is unavoidable. Be pragmatic and do the best job you can.

    Finally, the developer that created that database schema needs shooting.

  4. I would LOVE for others to look at my code. There’s little question that some knowledgeable programmer would reveal things that would leave me wondering why the heck I didn’t think of that to begin with. But I’m producing a prototype for a niche product that few others even understand the need for (because they’re not active users of this kind of software), I know how the entire integrated program must operate in order to have a chance in the market, and I’m painfully aware of how important it is for code to be as self-explanatory as possible — because I have to find and correct my own bugs. No one else has any incentive (financially or interest-wise) to look at my code, so finding someone qualified to analyze it is darned near impossible. On earlier coding projects, the pitfalls of shortcuts became very obvious, so I avoided most of those earlier errors in this project. But I’m certain that another pair of eyes on this would be enormously beneficial. So I absolutely agree with the author’s point here — while fretting that there’s no way to include that insight in my current project.

    • I am a novice .Net developer, I felt the same way. Until I decided to start reaching out. I have a Twitter account with almost 500 followers. That’s not a lot, but they are almost all .Net developers and front end developers. There are three different way that I have reached out and found others to review my code. 1) Post a status message on Twitter that says: “Looking for a .Net Mentor, someone to share a screen and talk code with”. I got two takers right off the bat and I’m talking to one of them on Skype as I write this and he has helped already in helping me refactor and think about my code differently. 2) I take Pluralsight courses and ask questions to the instructors. 3) I have read some articles I really like online and reached out to those people and asked them to help. In each scenario I have found others that were willing to look and some that were willing to stick around. Just put it out there, ….. ask.

      • Thanks for sharing that thought, I agree 100%. Developers are a weird species but when asked genuinely they are almost always there to help out, especially when asked for feedback. I’ve never had a bad experience myself.

  5. I also an a one man shop, but I asked I’ve of my colleagues who used to program years ago to review my code to ensure that I kept it as clean as I can. It also seemed to help by having sometime who isn’t a daily coder look at it forces me to explain my code and I can catch things I missed, even if he didn’t.

  6. I don’t know – I’ve only worked one place where we even had code reviews.

    I consider my style of development SODD (Stack Overflow Driven Development). So, even though I’m “alone” in a sense, I really draw from the “wisdom of the crowd” to try to stay on the “straight and narrow.”

  7. I agree and disagree.
    What you are writing is true for a lot of programmers.
    However: a really experienced programmer can perfectly write quality code without the need of code-reviews.
    Frans.

    • Of course, I never implied that because one is writing code in a solo process it will necessarily be bad code. In that sense the term “code smell” is incorrect.

      However, any code produced by an experienced programmer will be of higher quality if 1/ written in the intent of beeing visible code and 2/ the code is discussed with others.

    • …and any experienced programmer who believes their un-reviewed code to be perfect, is probably deluded.
      Ron

  8. Thanks for this insight. Indeed as coders we are weird!
    I am currently on 3 php mysql projects but unfortunately what you are stating is exactly what I have been doing for the past 3 years.
    I try as much as possible to be clear in code and do the documentation but I agree, we should always let others review for us.
    For my case time and budget constraints factor in since ours is a small private company.
    Though we are two, I take on the senior developer role most times, but it is really disturbing when I have to be called upon each and every time to rectify a ‘simple’ bug.

  9. This is the first blog I’ve read all of and enjoyed! Really good points, there’s always a bigger fish and your code can always get fatter! ;D

    I work in a team of 11 and only two of us can code, everyone else is a designer but you’ve spurred me on, I’m going to try get some code review’s set up!

    Thankyou!!

Comments are closed.