7 of the Hardest Things I Learned About Writing Software
Learning to write code is not that hard. With a book, Google, and a little free time just about anyone can hack something together. However, to become a good software developer you need a passion to constantly and continually learn.
Listed below is a list of 7 of the harder things I have learned over the last couple of years:
- Make choices - Not everything needs to be adjustable or needs an option. Many times, it just needs to work.
- Delete code - Sometimes even the best ideas will not work (or are not worth keeping). Admit that at this time, based on what you know, the tools at your disposal, and the requirements for success you just need to move on.
- NIH (not invented here) - Realize that even though you would have written something better, more scalable, and usable...if it meets your goals as is, you should focus your attention elsewhere.
- UI is more important than code - You can write the absolute best code the world has ever seen and if you present it like a turd, your code, to the world is a turd.
- Solve Problems - Realize that to more than 99.9% of the worlds population, code/technology are simply a means to an end. Software solves problems. The world really doesn't care how or why it works.
- You Are Different - When you write software, in most cases, you are not the typical end user. Your users are not looking for a challenge. For most, there are a million other things they would rather be doing than using your application.
- Documentation - Yes, documentation is necessary, but users do NOT want to read it. If your users are asking you for more documentation, the lack of documentation is not really the problem. Your application is too complicated. See The Paradox of the Active User.
Is there anything you would add to the list?
Comments
Javier Lozano on on 11.15.2007 at 9:32 PM
Nice post, Scott. One thing that we as developers forget is that we don't get paid to code, we get paid to solve problems.
barryd on on 11.15.2007 at 9:38 PM
8) It's never going to be perfect.
That whole 90% of the time spent on the last 10% of the software points to time that might have been better used somewhere else. When you're moving things around by a pixel and holding up release of something users might find useful then you're stalling and that may indicate other problems you don't want to admit.
David Hogue on on 11.16.2007 at 12:54 AM
Great list. Definitely agree with #1: it seems so easy to add "just one more option" (and then we get to support two paths through the code, two different behaviors that can confuse users when they see the other version, and we can split our time between them)
vincent on on 11.16.2007 at 1:40 AM
I'd add:
x) Accept that you evolve.
If you're going to open up some code from even only a year ago, it's sometimes confronting with what you've written (due to lack of experience, due to lack of time at that moment). It's better to accept it, and work with it, than giving in to the tendency to rewrite everything.
madkidd on on 11.16.2007 at 8:56 AM
Great post. If Community Server followed all of these rules it would be a much better product.
Scott Watermasysk on on 11.16.2007 at 9:01 AM
@Javier, @Barry, @Vincent, thanks for the additions. If I get a couple more I will do a second post.
Scott Watermasysk on on 11.16.2007 at 9:07 AM
@madkidd, like I said, I am still learning. As Vincent mentions, you always evolve. CS is constantly getting better and CS 2K8 will be infinitely better than 2007 (as I am sure 2009 will be to 2008).
Dewayne Christensen on on 11.16.2007 at 9:18 AM
One of the biggies for me: It's always my own fault.
If I approach debugging with the mindset that whatever's not working is my own fault, then I can always find a solution, no matter how screwy the problem. It's not a bug in Windows, it's not a bug in some driver, and it's not a network glitch. It's either me doing something wrong, or me misunderstanding how something I'm using works.
It's a big world--don't be hard on yourself for running into something unexpected.
George H. on on 11.16.2007 at 9:48 AM
Good post, but I think a proof read might be in order to fix the grammar. It reads like it was typed in a hurry.
scott on on 11.16.2007 at 9:51 AM
While I agree with most of these to a degree... I'm afraid too many people will read these as a justifcation for writing quick and dirty code. This is no time to abandon coding standards or best practices, especially in the arena of software architecture and design patterns. I'm all for making it pretty, but while cutting corners on the backend might make you the hero today, it will come back to haunt you later. When the software start to fall apart, or becomes cumbersome to maintain, extend, scale, etc. they'll forget how wonderful you were for delivering it quickly, and light their torches. So use caution when deciding to take the quick and dirty route. With all that said, it's is amazing sometimes how successful some software can be IN SPITE of being terribly written ;)
andrew on on 11.16.2007 at 9:52 AM
I disagree with a lot of your points.
1) If something can be designed in an extensible manner, it should be, even if it is harder and takes loner.
3) Just because something works doesn't mean that its finished, usability especially.
4) UI and code are equally important - what's the point in a fancy looking application that takes three times as long to use as it should do?
scott on on 11.16.2007 at 9:52 AM
one more thing... if you're spending most of your time solving problems, make sure it's not you that is creating them.
Jeff on on 11.16.2007 at 10:13 AM
I'm not quite sure I understand number 2. What did you mean? The description seems to not even fit the headline of 'Delete code.' Do you mean if you're not good, move on and do something else with your life? That's a little unsettling to me.
Also, this definitely needs to follow your own rule #5. Proofread, man. It may only be a blog, but you're publishing yourself where millions can read.
kevin on on 11.16.2007 at 10:20 AM
All 7 are great choices. Good post topic, great write up.
I would add "developers document their code". This may be assumed but more often than not I find it's neglected.
Scott Watermasysk on on 11.16.2007 at 12:03 PM
@George H,
My grammar is usually horrific, but this time it was particularly bad. Thanks for pointing it out, it should be a little better now.
Scott Watermasysk on on 11.16.2007 at 12:05 PM
@Jeff,
I am probably mixing ideas too much. I cleaned it up a little bit. In a nutshell, I recommending having the strength to simply say this is not working and it is time to try something else, start over, or even put it on the back burner until you come up with a better solution.
Scott Watermasysk on on 11.16.2007 at 12:09 PM
@andrew
1. I think this is why so many software projects are over budget and never make it to launch. What is the point of having extensibility if it is a dead project? The truth is a very small % of projects make it to V2 or need to be extended.
4. I am not saying code isn't important, but most developers overlook how important the UI can be. In most cases, developers develop and designers design.
Scott Watermasysk on on 11.16.2007 at 12:12 PM
@scott (the commenter not me :)
Similar to my response to @andrew. So few projects make it to V2. I am firm believer in getting your product out the door and worrying about tomorrow tomorrow.
There are always exceptions to every rule. I really hope I am not responsible for more crummy code. :)
Jayme Davis on on 11.16.2007 at 2:14 PM
Nice post, Scott. I especially agree with (in order) 4, 5, 2. As for the second comment left on this post (never going to be perfect), you have to accept that or you will NEVER complete a project. At the end of the day, you need 80/20.
Jayme
Erik Porter on on 11.16.2007 at 3:14 PM
Great list! Sooooo many developers overlook almost all of these. It might seem strange, but I think # 6 is the most important item. I would go even further and say every developer should make it a requirement to either:
1) Work with customers for at least a short time once a week. If it's just going through their complaints about the current app or suggestions for future features then that's fine. Read it. Ask them about it. Find out why. Interact!
2) Show what they've built to their spouse or any person who is not the target audience. It will be easy to tell what of their feedback doesn't apply because they're not your target audience and which things they mention were things you didn't think about.
3) Get feedback early and often. As long as it's not taking away too much time from what you're supposed to be building, the feedback you get is invaluable. You're building software for them, not yourself.
Also, the other item I would add is, for the most part, to focus on the audience that likes your product and make it better for them. The people who don't like what you build probably never will no matter how much time you spend with them and how many features you add for them. That time will be wasted and could've been spent making the product better for the people who already enjoy it. Your audience will grow much faster taking that approach than trying to make everyone love your product.
Again, great list! :)
Rick on on 11.16.2007 at 5:11 PM
You forgot one of the most important. If it aint broke, don't fix it. I can't tell you the amount of time I have seen people take to fix a problem that they discovered, that may only happen under an extreme set of circumstances or not at all in the real world.
Jeff Atwood on on 11.16.2007 at 6:19 PM
> Great post. If Community Server followed all of these rules it would be a much better product.
Ah yes, the 8th rule of software. Some of your users will be a-holes.
John Bäckstrand on on 11.16.2007 at 6:29 PM
I have to agree with the deleting stuff. Deleting stuff is at the same time the hardest thing to do, for some odd reason. It is also often the most rewarding thing you can do: remove cruft, and be able to focus on your products core. You may even be lucky enough tha't you can to reimplement everything you removed outside of your core, in a decoupled way (read: plugins, extensions etc) that dont break down (read: a too complex plugin system that starts being its own, too complex, infrastructure, requiring intra-plugin deps and more)
Steve Trefethen on on 11.17.2007 at 9:10 AM
Good list. I particularly like Jeff's addition.
I'd add: Focus on problems. Sometimes it's easy to get caught trying to tweak features your users don't have problems with because you _know_ they can be better when there are features that need real attention.
Regev Porat on on 11.18.2007 at 3:39 AM
Among other problems I’ll add this: don’t fall in love with your code!
Many times after us developers write something, we find it all too hard to accept the fact that it’s no longer needed. We’ve worked so hard creating our beautiful and clever components and classes, it’s our creation, almost like a child… so we tend to keep it in our solution, maybe with a few adjustments… and yet a good developer must know how to let go of his code, when situation changes.
Nikhil Lanjewar on on 11.18.2007 at 4:49 AM
A very nice compilation of THE hardest things!I agree wit almost all of em...wud like to add
x) Innovation Happens Elsewhere
This might point towards opensource (of which im a strong supporter ;-) ), but it sure does indicate a fact that whatever you're thinkin has already been thought in some part of the world! So its always better to check upon your counterparts before you start coding! Also, the problems you are facing have already been faced by someone residing in some part of this planet....So the "Innovation" of bugs n errors also happens elsewhere!(unless you're on some virgin machine or technology!) YOU ARE NOT ALONE!
Vitaly Gorn on on 11.18.2007 at 3:13 PM
Nice post, Scott. I would add the following among the others. Undoubtedly, it is one of the most valuable for software developer.
x) Write maintainable code. It is easier to write code than to read it, so write code that you (and others) will be able to maintain later.
Salman on on 11.20.2007 at 12:04 PM
Interesting points on software development. Probably one of the more challenging aspects is #1 (making choices). You have to realize early on their your feature set is not going to satisfy everyone, the key being to balance the feature set so as to make everyone happy.
Jeff on on 11.20.2007 at 2:32 PM
Good post, and I think Andrew's response is the source of many problems in many shops. Trying to solve tomorrow's problems today is a waste of time.
Sounds very 37signals, I know, but it's true.