Philosophy

Nobody cares about your code

Nobody cares about your code. It was quite a shocking moment when I learned this in my programming career. I would take great care in polishing my code only to find out nobody actually cares. It’s not the code that counts, it’s the product. Knowing that makes you more productive and improves the appreciation of your work.

Code is a tool

As programmers our job is not to write code. Our job is to supply software that provides some feature somebody needs. Coding is the primary tool we use to do this. But it’s just a tool. We don’t say a carpenter’s job is to use a hammer. Their job is to create something with their tools.

Some of our processes can however mislead us into thinking code is the product. Do we see refactoring as a way to get better code, or to get a better product? Portray it as code improvement and we find no manager ever wants to give us time to do it. Show how it leads to fixing a defect, or implementing a feature, and suddenly there is time for it.

Our software will be evaluated as a whole front and foremost. For every line of code we write we must keep that in mind. If the product is unappealing there is simply no reason to look further. It doesn’t matter if we think we’re using our tools well. If the resulting product isn’t good, then we’ve basically failed to do our job.

This is not to say the code may not be valuable, or even reviewed as part of a requirements check. Security and fault tolerance are best approached with good craftsmanship and the correct libraries. Indeed, it’s our job here to make the relevant bits of the code stand out and keep the rest uninteresting. The quicker a reviewer can get in and out of our code the happier they will be.

Code as a tool is incidentally why it’s important to know several languages and have used many frameworks. It’s why knowing math or complexity theory is useful, but not required. It’s why IDEs can be both amazing and terrible traps at the same time. Our flexibility as a programmer is directly related to our toolset diversity.

Features dominate

Think of a meeting with the product manager, or customer. How do we communicate with these people? Do we tell them how many classes, or lines of code we’ve created? Do we give them details about the deployment scripts, our exception strategy, or database schema?

Unfortunately the answer is often yes, we do. And look at their faces when we do this. They’re bored, disinterested, and looking to move on. We’ve just recited a bunch of details which are of zero value to the product owners. It’s not that they don’t understand, they just don’t care.

Just imagine if our graphic designer started giving details about the layers they used in Photoshop. How many objects they created, the gradient stops used on the brushes, or the cool automation scripts they’ve written. We don’t care. We just want to know if graphic assets are done or not.

We should be communicating the status of features: import is now complete, but XYZ support is still lacking; it’s now working on most phones, but model Q still jitters; we’ve got the client app running and usable, though still quite spartan. These are the interesting details to our manager, or customer. These details tell them something they can act on; something to aid them in their planning.

The library is worthless

I’ve seen many questions online about protecting source code. A programmer does client work and reuses their own private library. Now that client wants the code and the programmer is uncertain. They don’t want to just give away this valuable library code.

Consider first why a client actually requests the source code? Maybe they want the assurance that they can continue building their product even if the programmer disappears. Maybe they want the ability to audit the product for security or legal purposes. The code in and of itself is not what they want. It’s just another asset needed to fulfil some other activity.

Though creating a library may be the right thing to do, that doesn’t give it inherent value. The library is likely only valuable to us in that it lets us develop our projects faster. It may be the most important part of our business in fact, but another programmer may casually discard it as uninteresting.

What if our library is truly special? If we honestly believe that then we can make the library the product. We can share the code, or even sell the code, and see what happens. Just bear in mind that very few code products are even moderately successful.

It’s a worthwhile exercise for any programmer to do this. Just to realize the truth about how little other programmers care about our work. Think about your own project. When you picked a library was it because the code was awesome, or because the features were great? Did you even look at the source code after you installed it?

Yes, but…

Doesn’t this give us liberty to write crappy code? No, it doesn’t. Quality workmanship is necessary to produce a quality product. It doesn’t matter that nobody actually cares about the code, it’s still a vital tool in getting the job done. Perfectionism is a curse, but we simply can’t meet the requirements if we use the tools ineffectively.

To use the carpentry analogy again, a dull hammer will pound a nail in just as well as a shiny one. A rusted hammer however may break and injure somebody.

Our goal as a programmer is to polish the product, not the code. If we wish to be effective in our role we must be addressing the features, not the tools. We need to understand the true source of value in our product.

68 replies »

  1. I believe every entry course in CS should start with reading and discussing this article.The problem is that most of CS students and then employees never get that enlightening understanding. Or get it too late.

  2. In general the principles how to deal with non-programmers are correct though the analogy seems completely wrong. From carpenter’s point of view code is a material, however tools are language, compiler and so on.

    • Yes, perhaps code is more like a material than a tool. But at the same time we could say the compiled/packaged final form is actually the material, and code is what is used to build it. I think grouping tools and material together in this article makes sense. Most people equally don’t care about what libraries, code snippets, and other materials the programmer is using. Same with the carpenter. They only care if bad materials are chosen and things start to fall apart.

  3. It’s more nuanced than that. My position is more this: nobody cares about your code as long as it’s good. That’s the trick: when you produce good quality code, you liberate stakeholders from caring. You are able to provide rapid turnaround on features/fixes and whatnot. The team can grow comfortably because they work in a sane code base.

    However, the instant your code crosses into nightmare territory, suddenly, everyone has to care. They don’t want to, but it begins to reflect in all other aspects. That rapid turnaround goes away; bugs are produced with every change; it becomes harder to grow the team as everyone resents working in the code.

    Is a car engine a good analogy? Nobody cares about their car innards… until they start failing. XD

    • You are correct. I was trying to indicate this with the note about good craftmanship. You can’t possibly achieve the product requiremetns if the code is so bad as to be faultering in its role.

      I still don’t think people really care itself when its so bad. It’ll more just be used as evidence of incompetance and a measure of how to fix things. Beyond just saying “it’s really bad” to the product owner, and estimating a fix time, I don’t think they care about the details of “how” it is bad.

  4. A related thought – if code doesn’t matter much, how important are mandatory style guidelines that programmers must follow…

  5. While I agree that customers don’t care about the code we write, the members of your team do. Have you ever end up maintaining code after somebody who “I did’t care”? Awful right? Well, then we should care, even out of respect for our coleagues and future generations of programmers who may end up maintaining our code after we move on.

    From a more selfish point of view, well written code gives us the chance to stay out of boring parts longer, instead of being stuck at fixing defects or having to hack new features in. Every refactoring I’ve done started with the idea how I’d hate to add more features to the existing code base.

    • I think you an masterbuzzsaw are touching on the same thing, nobody cares so long as its acceptable. You even bring up the point of staying out of boring parts. This is basically what I meant when I said people want to get in and out of the code as fast as possible.

      My main point was meant to apply primarily to people external to your immediate team. No product owner or customer cares about the code. No user of your libraries cares about your code.

  6. Nobody is interested in how I code until I say: I reduced the loading time from 10 minutes to 20 seconds.

    • I don’t think this changes people opinion about the code itself. Sure, they are quite happy the product has improved, and they’ll even reward you for doing it. It still doesn’t mean they care about the code.

    • In my experience human curiosity is a factor that promotes the interest towards creation, in this case coding.

    • Not all the code improvements are bottomlineable with a benchmark. Sometimes the improvement is “now it’s easier to maintain it”. How do you quantify it? No quantification, no reward.

    • It occurs to me that one way to quantify that could be how long a change or adding a feature to the system will take now to implement versus how long it took before… ? What do you think?

  7. Nobody cares about code when you code a small application and you work alone. If you work in a 10+ team with people moving in and out and with developers continuing the work other started you really care about having code that’s clean and easy to understand by others.

    Suddenly refactoring makes sense as it will maintain unchanged the end-user experience but will lower the cost of new features as developers will interact better with the existing code.

    • We have to be careful about why we refactor code. I disagree the goal should be to keep the code “clean”. The goal should be specifically to enable the development of a new feature. This may not sound like a significant distinction but I find it prevents refactoring for the sake of refactoring.

      It also gives a clear limit to the refactoring. Once you can easily implement the new featuer you should probably stop. It doesn’t matter if the code still isn’t in the preferred state. I’m not sure you’ll reach an ideal code state.

      I think we mostly find our team mates don’t look too closely at our code either. During review we tend to look at unit tests and the high-level API. Going deep into the code is usually not productive.

  8. I agree with the essence of the article.

    As a developer, my aim is to produce code that allows me to produce quality functionality that solves the customers problem in a timely fashion. Which means that the code has to be clean enough to be maintainable (by me or someone else), but it doesn’t have to be a work of art.

    As a development team member, I want my code (and everyone else’s) to be clean enough that it doesn’t get in the way of developing the next feature etc.

    I don’t care if the braces don’t all line up, or the function names aren’t exactly what I’d have named them, because I’m a big boy who can deal with it.

    The computer, the BA, the tester, project manager, customer etc don’t care what the code looks like as long as it doesn’t get in the way of developing the next feature and doesn’t cause rework.

    The carpentry analogy is a good one. Those arguing the toss on whether code is a tool or material are missing the point. Carpenters follow standards for two reasons
    1.) so their buildings are more likely to remain standing, without having to make up the structure every time
    2.) and most importantly in the context of the analogy, so that the carpenters who follow (renovations etc) know what to expect.

  9. All the above is true for mundane journeyman code that is redone all the time in our industry.

    Most code is not a masterpiece for lessor mortals – it is more “Family Guy” than “Hamlet” – and puts meat on the table.

    If you did manage to write something that would be interesting to the William Shakespeare’s of the code writing world, you would have to find one to read it.

    They are out there, though you have to look.

    If you are leading the boundaries of what can be done in some field like AI, computer graphics, security or something where innovation is valued, then your code might have that little bit of awesome that we all aspire to.

    Years ago, I used to read great code from graphics programmers at SGI who went to nVidia and Apple afterwards – it was sublime, and required one of the team members to explain the subtleties, but like a student with a great English teacher, my eyes were opened.

    We can all write code that our peers would care about, but to make it worthwhile, we need customers who care about it.

    Sadly, most of us subsist in the “pulp code” strata, and have not managed to break out of that ghetto to the next layer.

    Master coders know and recognise each other like world class writers know each other – by their code.

    Like in literature, there are more surveyors than purveyors these days.

    Shakespeare had many peers in his time, and did not just magically appear.

    If you care about your code, and want others to, you need to write code they would care about. You also need to read lots examples of great code so that they become the norm for you.

    Adapt.

    Evolve.

    Break out of the ghetto.

    • I’m not saying not to strive for writing quality code. Indeed your goal should awlays be to improve and try to always write the best code you can.

      The idea that nobody cares is meant to help you prioritize your efforts. There is never enough time to create the masterpiece we want, so we’re forced to take shortcuts and reduce the effort in some ares. Being able to recognize that code need not be a masterpiece enables you to make better decisions about what to work on.

  10. We’ve just recited a bunch of details which are of zero value to the product owners. It’s not that they don’t understand, they just don’t care.

    >> Having such clients, who just walk from buisness to biusness and who hide any idea to talk from face to face or to motivate would be a cold place to work. If somebody understands, he could also answer, not to go into detail, but to show respect It seems you just arranged with the always busy bosses.

    These details tell them something they can act on; something to aid them in their planning.
    >> In my opinion not everyone in buisness should have got a computer. Only those people, who can help theirselfes in emergencies.

    We can share the code, or even sell the code, and see what happens. Just bear in mind that very few code products are even moderately successful.
    >> This view leads to no development. Imagine how much programmers keep their libaries private, because there’s no market für libaries. An because of the small market noone will look for libaries, because its a waste of time to go in a shop with not many offers.

    >> Stating a CS course with this article would make the course much less interesting and lead to fewer students. The aspirants would realize, that CS is just a couse of studies like everyone else, after that you get work where no one cares, even they could. Maybe so the companies would get the employees they want and of course the deserve.

    • You’re mistaking caring about the code for caring about your role. I’m specifically trying to get people not to stop caring about their code, but to see their whole role in software development. If you put your head exclusively into the code and see the project only from there you’ll find your contributions are never noticed. You will never be recognized as a standout player.

      It’s the programmers who look at the whole project, and learn to prioritize and communicate with product owners that stand out. People definitely care about the product, but the code is not the product. That is the key point to remember.

  11. Organizing the source code for a product has absolutely zero value to a customer. It does however play an imperative role within the organization. If your programmer quits his job and you hire another one, you’d be interested in continuing your product not having to develop it from scratch again because the code is not understood.

    • I don’t see all the comments here being in support of what I wrote. I’m very glad to get contrasting views. It’s important for us, as a profession, to discuss these things.

  12. Depends on where you work at.
    This is probably true for a small team working on a product, but if above you (the developer) there are layers and layers of managers, architectures, senior developers and all this kind of stuff, your product is the code.

    • No. If you’ve got senior developers above you who will be reviewing your work, then their product is the set of features. Yours is the code.

  13. I think the premiss “Nobody cares about your code” is nobel but seems flawed. If we see code as a tool to produce a product as in the carpenter’s analogy, a user of a chair made by the carpenter doesn’t care about the tools used to create the chair, a good carpenter WILL care about their tools because they make it easy for them to make a good product efficently. Therefore when we talk about features of software maybe we should take note that some features are exposed to users, speed robustness, usability, and other features of software are not, such as maintainability, extensibility. It seems that such features of the software not seen by a customer or end user are simply being taken for granted as, “if your writting software right you’ll get these features for free.” I’m concerned that there will be certain software where the importance of such ‘internal’ features require decisions being made on the importance of such features compared with ‘customer exposed’ features, just because it may save the business time money and reputation.

    • I consider extensibility to be a feature valued by the product managers. I’m okay with refactoring being done specifically to pave the way for a feature to be implemented. But I think that feature should be known first, we shouldn’t just be refactoring for extensibility without knowing what extensions we’ll need.

      I do strongly believe in refactoring, but I consider it to be the step prior to feature implementation rather than after. Especially since nobody will ever give you time after the feature.

      And although nobody cares about the code, it doesn’t mean the code isn’t important. If somebody is writing crappy code the product will suffer. There is however a big difference between adequate code and extravagant code. And at times shortcuts will need to be taken as projects do not have endless budgets. It’s a matter of priority.

    • “And although nobody cares about the code, it doesn’t mean the code isn’t important. If somebody is writing crappy code the product will suffer.” – This seems a confusing maybe even conflicting concept, hence my feeling is something isn’t right with this premiss or the manner it’s being expressed.

    • If we are speaking about programming as an art form then my point is ever more poignant.

      Even if we consider programming an art, we can’t expect anybody to appreciate our code as artwork. Functionality will be most people’s foremost concern.

      Even in programming competitions the fucntinoality of the code is usually the first criterium for success. The beauty of the code always comes second to that criteria.

    • Didn’t mean to be flip about your well thought out article, but alas I didn’t mean to say programming as an art form either. I meant that Dijkstra and the likes of him create algorithms expressed as code. And that’s were code matters, you can have it done it 20 different ways, but he can prove the worst case scenerio and the best case scenerio for the execution efficiency of the code. And that matters alot, it is permeates throughout the software and system our society is based on. It affects how fast our compilers work, how fast your internet connection is, to whether you cell phone call gets connected. In his case – and many of those who architect solutions – the code is the product.

  14. I’m sorry, but I cannot agree with the article. The code is not just meant to be executed by a machine, but also to be read (and understood) by humans, sometimes long after it was created. For this reason, the code matters. Not for the users, but for me and the other members of the team.

    • I find there to be a significant difference between code that is maintainable and code that is pristine. I’m arguing for people stopping at the point where it’s uncertain if further improvements will ever be useful.

      You are correct that as you get into your team, and close to the maintainers of the code, the code will start to matter more. But this is just a fraction of the people involved in a typical software project. Programmers on other components of the project won’t likely care about your code even.

      This is no excuse to write bad code. It’s meant to be a limiting factor in needlessly refactoring to satisfy unknown requirements.

  15. I’m stealing this: “We don’t say a carpenter’s job is to use a hammer. Their job is to create something with their tools.”

  16. I disagree.

    There is a general rule in the field of IT: no one will call the IT department unless there’s a problem. I mean, you said it yourself: “Quality workmanship is necessary to produce a quality product.” This is precisely the reason someone will care about my code: to fix a problem.

    I just had a situation where our Statistical Analysis System (SAS) installation at our company was just upgraded to the latest version. One of our senior statisticians shared with me a SAS program written 10 years ago that all of the sudden no longer works since the upgrade. We’re confident something relatively minute needs to be tweaked per the upgrade… but alas, when we examined the source, we see lines upon lines of spaghetti code.

    When I mentioned the need of refactoring, the senior analysis guy cringed. This program has been held as a standard statistical analysis routine for years based on the practices of our company. It’s becoming a nightmare to resolve this simple issue, not only because of the spaghetti code, but because of the prospect that the ‘held standard’ will no longer be ‘valid’ after modification.

    So, the “ain’t broke, don’t fix it” mantra no longer applies in situations like this. The moral of the story: Yes, someone cares about your code, because sooner or later, someone will have to look at it and understand it quite possibly without the benefit of your presence.

    • I totally agree with the situation you described, but the author is right too. When you are producing code the end user doesn’t care how many lines it takes, just that it works well. You are caught in the trap where the code can’t continue working without changing it and the customer just wants it to continue working without changing it. You are probably right that the code should be refactored to work better at the same time. The customer is also afraid of the “Now that we are here, let’s fix this too” infinite loop. So, is resisting getting on the infinite loop that doesn’t really exist. (Until you find something else that needs fixing.)

    • I will steal and paraphrase a comment from Google+: The most defining attribute of software is that it is SOFT.

      That piece of SAS code stopped being soft-ware when it could no longer be easily changed and adapted to a new reality.

    • I think there is a significant difference between the field of computer science and the field of professional programming. The expectations I’d have of a computer science researcher differ from what I’d expect of a programmer.

  17. Nobody… It is such a strong word, but it is true that the client could give a rat’s behind. They don’t care about your diagrams, they don’t care about your process, they just care about your product. In fact, they care so little about those other things, that if those things hinder the progress on the end game, they will find someone else to do it.

    Programmers need to be product motivated, rather than process motivated. After all, we don’t code for code’s sake, or even for other programmers (unless we are hobbyists). We code for the end user.

    It is very much like construction workers, in that we don’t really care if they used DeWalt, or Ryobi, we only care that the house was created satisfactorily, with little to no defects, and was done in a timely manner. We don’t care who the foreman was, we don’t care what process they used, be it Agile or PSP (however, we would like to see incremental improvements), and we certainly don’t want to hear about how the process slowed the construction efforts.

    Does that mean we shouldn’t take pride, or care, in our work? You can take that attitude, but it will show on the end result.

  18. As developers we constantly struggle to satisfy users and peers. Users don’t care about the code as you said, they only want it to do what it’s supposed to do, do it fast and be reliable. Most of our peers love code that is readable and maintainable. Finding the balance is the key and all this makes me remember the words of a wise boss I had several years ago who said that “perfectionism is the enemy of good stuff” and he explained that there is no perfect thing and the more you try to make it perfect the longer it will take to deliver… so somebody will release something not as good as yours but being first in the market is, sometimes, all that matters.

  19. Wrong, wrong and wrong. The compiler is the tool, not the code. The code *is* the product literally and figuratively.

  20. This is a very flawed analogy. Code is the product not a tool. No more than wood is a tool for a carpenter. It is raw materials, which the quality of the materials the customer cares about. If bad materials are used the product may not last long, which the customer will remember.

    Code matters.

  21. This is true, but sometimes management forgets that too. I remember when they proposed measuring productivity by lines of code written per day. I kind of blew up at that thought because I had just looked at some code the day before, realized it was terrible, wrote 20 lines of code,deleted 120 lines, the code was more efficient, one less bug, and easier to read. I’m going to be dinged for losing 100 lines of code that day? I’m going to be judged on lines of code per day when I have to go to meetings, find out new requirements, get agreements from the customer on what will be produced, design how the code will work, and then start writing lines of code!
    How about I just supply 100K blank lines daily in a comment section, that surely should satisfy anyone’s line counting fetish!

    • Any business that measures programmer productivity by something like code metrics is most likely doomed to failure. I have yet to find a code metric that accurately provides any kind of insight into the quality of the product.

  22. All the “yeah, but’s…” are exhausting; that’s why I prefer working as the sole developer on a project (and have been fortunate in that sense).

    The previous customer I worked at had myself building a project from scratch while another “team” was working on a new release for an existing product that was already one month “late”.

    Two years later I had already deployed multiple releases of a significant product across the US and the UK (to excellent reviews), while the other team still had not deployed; though they did brag about how in the meantime they had created “500 unit tests”.

    It’s all about “SHIPPING” (software); as for the rest … nobody cares!

  23. Code certainly matters to the Chinese. The NSA reports not a single corporate environment they’ve ever looked at didn’t have Chinese malware concentrated around software servers. Not one. Of course, the brain-dead coders and their managers who use easily reverse-engineered crap-ware like .Net obviously don’t care about their own code, so in that sense the premise of the article is valid. Hopefully the Chinese will steal that stuff, and not my code.

    As to knowing a bunch of languages, are you joking? Being able to write derivative code on systems whose innards escape you in five different script-kiddie languages gets you what? A job programming “security” for Target? Full in-depth knowledge of C++ and a decent scripting language will get you anywhere you need to go and the fundamental knowledge to write anything in any language du jour… oh, that’s right, the author doesn’t know C++, guess you really can’t appreciate what you don’t understand!

  24. A product is never complete. What makes it possible to continue improving and extending a product is concise, organized, understandable code that is both flexible and re-usable. That is what actually makes a product work, and makes maintaining the product doable. It also constructs elements that can be used in other products.

    In other words, this article is full of platitudes and nonsense.

    • Just another point to consider. It takes the same amount of time to create crap code than doing clean code. It is just a matter of having the skills and caring about quality but you don’t need to spend more time to do it rigth on the fist try.

      Having to refactor something means the one that did it initially probably failed.

    • It is quite impossible to conceive that crap code takes the same amount of time than doing clean code. The use of a copy-and-paste solution from Internet almost occurs instantly while the times its takes studying and analyzing the code tends to improve the solution. And not, sometime you refactor because requirements changes or for the need of a new feature… refactoring a code does not means, hey someone did something wrong here!!

  25. Programming per se is a tool. Not the code. Stopped reading when it said code was a tool.

    That’s why we often end up learning intrinsic matters of the business in order to produce code.

    For a brief analogy of my point of view, code matters for people the same way human DNA matters: Most people will think “oh, nice. But I don’t see it. And I’m not interested”, and others will say: “whoa nice, let me check that”.

  26. I don’t agree. The code is not only the tool, it is also the material. If you build a car with crappy material, will it be a good car? Think of 2 identical products, one written in crappy code, and the other one with good code. Both work perfectly. Now the client wants to add a new feature. Try adding it to both projects and you will understand what value good code has.

    • I agree with this, but it’s missing one very critical point. To keep with the analogy, far too often products never get released because the entire budget was spent on top-notch materials before the product was completely built. The product with more practical materials however was able to complete the product with the available budget.

      Too many projects fail, or falter, becuase they simply take too long to achieve, or simply never achieve, their requirements. Instead they focus on material, or tool, losing site of the true requirements.

    • Good code may require more skill and experience, but generally LESS TIME to produce than sloppy code – and the benefits multiply as a project expands.

    • All well and good when you have a limitless budget and limitless timeframe. When you are pushed to meet unrealistic timeframes or lose business\contracts\job then what do you do? Spends time refactoring and making everything perfect? Or get the product delivered, get paid and deal with the other issues at a later date if that time comes.

      Everyone’s conditions are different. Not everyone can be tarnished with the same brush.

      Great article that a lot more ‘code snobs’ need to read.

    • No no, the code should be good from the beginning. The programmer should try to write good code right from the start. The question about refactoring is another question.

  27. I think your article has a lot of value for developers, because it helps them approach their code from a pragmatic point of view. Nevertheless, I think an aspect that was missed is employee retention. If you as a business only care about the end product and disregard working conditions (which in my opinion extends to legacy code developers have to work with) you shouldn’t feel surprised if you have a hard time holding on to your talent. I think we need to keep in mind that software development is a people business. At the very least until we can figure out how to take the human aspect out of writing code, code quality will matter.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s