11 Personal Programming Assumptions That Were Incorrect
Today I got side tracked and spent an unreasonable amount of time on StackOverflow.com. One of the questions I was looking at was What is your longest-held programming assumption that turned out to be incorrect?
Many of the answers immediately resonated with me, like Instantsoup’s answer That people knew what they wanted and JohnFx’s awesome answer about comparing his knowledge to the collective knowledge of all other programmers. Other answers reflected a poor initial understanding of the language or technology, many of these I was fortunate enough to not relate to.
As you can imagine, I immediately started coming up with my own answers, so I continued reading to make sure they weren’t already there. But as I read, I came up with more initial assumptions which proved to be false. I thought I’d pick out the best, and answer with that one, but realized I had a whole blog post!
So without further ado; here is my list of assumptions about programming and the industry which proved to be incorrect:
- The customer and user are the same person.
In consulting with custom in house software this is (almost?) never the case. The customer has their eye on the budget and many won’t give 2 cents to make something easier for the user. - You isolate and kill all bugs without exception
Truth is; there will always be bugs, and what gets fixed is an ROI decision. - Writing beautiful software as an act of craftsmanship
It’s taken a LONG time for me to get it through my head that it’s just another financial investment, where you want to get as much as possible while giving as little as possible. However, although I know it intellectually, I still don’t ‘get it’. - Working 24/7 would be rewarded
Truth is, working all the time will burn you out, lower your productivity, and cause you to make stupid mistakes which reflect on your professional abilities. - Vendors can be believed
In my experience, don’t believe the product will integrate as seamlessly as they say without getting their API documentation and building the whole integration mentally first. - You are not actually working from the monitor.
With today’s GUI platforms, this is largely abstracted out, so you can actually program believing that a textbox is a physical entity. But when you are managing your own graphics, that textbox isn’t going to capture your keyboard presses and display them, unless you provide the illusion. It’s actually up to you to capture the keyboard input, and adjust the memory buffer containing your screen image with the newly typed letter in the control. This was a real mind bender for me, when I first got into this. - That I wasn’t a very good programmer
Like JohnFx’s answer, I was unsure about my abilities. I don’t have a C.S. degree, and was overwhelmed by the depth and breadth of the knowledge out there. But the more people I meet, the more I realized, I might actually be pretty good. Don’t get me wrong, under malicious attack, there are many who could expose and exploit the holes in my knowledge, but in my general area (business software), I’m finding that I’m not too bad. - You need to / should grok a language or tool before you even start.
Groking is a powerful way to start with a new language or tool. But in reality, especially with consulting, there isn’t always time. If you can hack something together in a completely unfamiliar language/tool/framework/paradigm/etc in 5 days, and it would take somebody who knows it cold 1 day, but it would take you a month to grok it … you hack. You may not want to, but from a business perspective … that’s the correct answer. - You don’t say you know something unless you’ve grok’d it.
Well, you don’t need to have too many conversations with too many programmers to know this idea is not wide spread. - Other programmers saw beauty in their work.
Personally, a well written piece of software is similar to a piece of art. It’s my form of artistic impression. It’s my baby. However, there are many people in our industry who do this 9-5, and appear to get no more enjoyment out of it, than I got out of a factory job I had in my teens. - The best programmer is recognized
In retrospect this is almost laughable, at least in consulting! If programmer A writes a wiz bang sub system, takes 2 weeks, it’s flexible to extend, and the core system never requires maintenance. Programmer A would not be held nearly in as high regard as programmer B who takes 1 week, hacks together a piece of garbage which is a nightmare to extend, and is maintained with multiple bugs for it’s life time. This is unfortunate, but in my experience, only a very capable manager would know the difference.
Copyright © John MacIntyre 2009, All rights reserved
WARNING – All source code is written to demonstrate the current concept. It may be unsafe and not exactly optimal.
11 Responses to “11 Personal Programming Assumptions That Were Incorrect”
Trackbacks/Pingbacks
- Links for the week — The Endeavour - Ping Back Links for the week Some interesting links I ran across this week. Software PoshBing, a PowerShell interface to…
Senior Software Consultant working in the Toronto area. I specialize in Microsoft technologies and have a long history of taking software development projects from idea, through development and implementation, and years of maintenance.
Always looking for interesting projects. 
Great post. I totally agree with many of these points. Number 11 could probably be clarified a little better as a “very capable manager” leaves some room for interpretation. Perhaps some distinction that this capable manager should really understand the software lifecycle and not just be some run of the mill project manager that just happens to be looking after a software project this time around.
Thanks for the comment Ben. And yes, your assumed distinction about the manager is what I intended.
I still struggle with #8, wanting to master a language before I use it. Not only is this not necessary, it’s probably not possible. You’ve got to write code to learn a language (though it doesn’t have to be *production* code). At the other extreme, however, are the people who use a language without ever learning it (i.e. JavaScript).
If I understand right what you mean by #3, I don’t agree. I think that if you want to be satisfied doing software development and continue for years without burning out, you have to write code of which you can be proud.
I’d say that code that is clear, flexible, and maintainable gets you the most in return for giving the least, in the long run. Coincidentally, that lines up pretty well with my definition of beautiful, well-crafted code.
@John
So true! We learn by doing. It can be intimidating to learn something under the pressure of generating business value while learning something new. However, sometimes I need the pressure of creating something real to force me to dive into a new language.
Ben
Jason-Actually, it sounds like we do think a like. I personally, don’t like or agree with my conclusion to #3 either, but the business aspect of it (at least with consulting), seems to push this way.
Well while i have to agree with all the points that you raised i have to admit that there are so many more issues and points to be raised. You could probably write a blog entry on each of the following areas like the end user, the customer and the programmer amongst others.
#11 is an interesting one – it appears that organizations tend to actually reward bad quality. The heroic last-minute effort required to fix a high profile bug always gets more praise than the code (and coder) which didn’t have that bug in the first place.
Ville-In my experience, most managers I’ve worked for don’t know much about programming, and if you don’t already have a high trust/respect relationships, they just don’t have any metrics other than time. It’s actually quite shocking how few (none in my experience) measure whose changes require the most bug fixes.
Seems like #11 is the most thought about point. I am on the fence for this one. It all depends on the manager. In most cases, if the manager has grown from being a programmer, he/she will easily notice if a programmer has produced quality work or it is going to be a tough time fixing bugs.
‘If’ the manager is/was a dev, then you’re correct, they’d know. But unless you work for a software company, then they won’t. And in 15 years, I’ve only worked for 1 software company.
… but I can tell you, it was very nice to work with somebody who knew what I was contributing, rather than worrying about image.