Kenn’s 21 Rules for Software Development

As someone who’s been an information technology professional for over three decades, I’ve learned a few things along the way. It has been said that a smart person learns from their own mistakes while a wise person learns from the mistakes of others; I have made a buttload of mistakes, so make of that what you will.

A while back, I started making notes about things I considered important advice for software development. At first, the ideas flow quickly because they were things I’d thought, experienced, or been affected by more often. The last few took months, because I wanted these to represent things I thought were really important.

So without further adieu, here are Kenn’s 21 Rules for Software Development:

1. Everything is cyclical. When it’s trendy and exciting for the entire industry to cycle in one direction, rest assured that someone is coming up with a great way of re-envisioning and reimplementing the opposite methodology. Someday everything you’re doing right now will seem archaic to someone else, and it’ll probably be within the lifespan of your career.
2. The first solution that pops into your head probably isn’t the best one, and even if it is, you won’t know until you come up with other possible solutions with which to compare it. Listen first; think about solutions later, and never stop with the first one that comes to mind.
3. There are different ways to learn, but as a developer, there’s only one best way: code stuff. Find reasons to make things, and you’ll have found the best teacher ever.
4. Ignore those threads/posts about which language is best and which ones suck. Learn several languages over time; each one will teach you things about the others. Learn the principles of coding and be ready to change languages when one is better suited for a different task (or when your employer decides to switch to something different).
5. Learn from your past, but don’t live in it. A lot of things in our profession never seem to change (logic is still logic, and everything ends in a one or a zero), but a lot of things do change… really quickly. Pay attention to the difference between a valuable lesson learned and baggage that just holds you back.
6. Software development isn’t a job; it’s a career. How would you feel about going to a doctor who graduated medical school 30 years ago and hasn’t learned anything new since? If you don’t have that level of passion for it, find something about which you do.
7. Stack: the entire set of software and technologies required to build a website or application. Full: “Complete. Entire. Maximum.” (Dictionary.com) It’s a challenging title to live up to, so consider that before using it on a resume.
8. There are many factors that can define “better.” Professional developers get paid, normally by companies that have to make money in order to afford them. “Better” might lie within the tools the company’s team already knows or those for which they can best find staff later on. Reducing complexity might be more important than many other factors, and time to market might have critical implications that would be impacted if you change too much of the client’s world.
9. “Done is better than perfect.” It’s not original to me, but I sure use it a lot. In fact, I use it like a mantra, because it’s something I have to repeat to myself often to keep myself on track.
10. The customer (or client) isn’t always right. If s/he were, it would mean that s/he knows everything that you do and that you’re not needed. However, there’s usually a valid reason behind what they want, and you need to find that reason and then translate it into a workable technical solution.
11. I have heard for many years that “those who can, do; those who can’t, teach.” I say, “those who can, do; those who care, teach.” Helping others grow matters more in the grand scheme of things than a lot of what we spend our time doing. Also, there’s really no better way to gain expertise in your field than to figure out how to share what you know. Embrace opportunities to teach.
12. Plan first; code after. As software developers, it’s hard to resist jumping right in and starting to put code to IDE while the suggestion that there’s something to code is still echoing in our ears, but don’t succumb to the temptation. If it’s worth 200 hours of coding, it’s worth 20 hours of planning.
13. UX and marketing are vital to everything we developers do. Our products need to work, need to be maintainable, scalable, fast, etc., but it won’t matter if users hate to use them or if no one knows it exists. Respect those disciplines and those who do them well.
14. Don’t try to scale from the beginning of a development project. This isn’t my rule, and now it has become somewhat ubiquitous among software-development advice. So why am I including it here? Because I’m still trying to get it through my own thick skull!
15. When I started (yes, I’m old which means I’m wise so just listen already) we called our field “data processing.” That label is long gone, but it’s still all about data. Data is stored in databases, and generally accessed via SQL. Databases are a huge part of the developer toolbox, and knowing more about them can give you an edge that a lot of your contemporaries may have overlooked.
16. The number of tools and libraries that are available to developers and non-developers alike is staggering. When you really spend time learning a tool, you gain something invaluable: expertise. You start having the brain equivalent of muscle memory, and you can produce better results faster. Find tools that feel like a good fit for the way you work and think and learn them really well. Wait for compelling reasons to jump to the next new shiny thing.
17. If it ain’t broke, don’t fix it until you’re sure that nothing else is broken; that way you know the almost inevitable ensuing breakage came from what you just did.
18. The customer isn’t always right; that’s why they hire experts like us. We’re not just there to say “yes ma’am/sir,” and to do so is a disservice to them. Say “yes” to their goals, but be willing to respectfully open a discussion when they start getting into the “how.”
19. Iterate in small bits. As developers, we all know that when we wait too long to publish, when we make too many changes over too much time, the chances of something going wrong increases. But what about the people who use the software? What are massive changes going to feel like for them when they’re just trying to get things done? Small iterations and thin vertical slices are better for everyone.
20. One definition of an expert (and one that I really like) is someone who knows how much s/he doesn’t know about a given topic. Strive to become an expert and then you’ll realize that you need to stay humble, keep an open mind, and keep learning every single day.
21. “Know Thyself” was written over the entrance to the Oracle at Delphi, where the rich and powerful came from miles around to find answers. I think the person who put up that sign was probably smiling to himself when he did it because he got the inside joke. Whether it’s about your career or the other parts of your life, nothing will ever help you more than honest self-observation and examination. Sacred cows make the best burgers.

What you may notice about this list is that a lot of the same rules apply to life in general as well as they do to programming. Make of that what you will; personally, I’m still kinda thinking on it myself.