Rules | charlie on software

Posts Tagged ‘ Rules

My Rules of Software Engineering

updated: 08/28/2014:

When I was teaching at UIUC, one of my assistants shared with us a list of rules that he had put together about how to thrive in the software engineering field. After teaching over 1000 students software engineering at the University of Illinois, and now working on a large project in the industry for a while, I’ve decided to revisit those rules and change them to fit the landscape as I see it.

Charlie’s Rules of Software Engineering (adopted from Mike Lynn’s rules)

  1. Quality code is portable, secure, easy to debug, and flexible enough to be used in ways that were never intended….plan accordingly.
    1. If this isn’t the case, then you’re probably not writing very good code.
    2. Or your code is too specific and should probably be generalized.
    3. Or you are trying to ensure job security, any intelligent manager will fire you.
      1. Your job is almost never as valuable to the company as you think it is. Keep this in mind. Constantly find ways to improve your worth to your boss.
  2. Kludges that we’ll fix in the next release never get fixed in the next release.
  3. If you don’t do it right this time, you (or some poor bastard that replaces you) will have to do it right later.
    1. It always costs more to do it later.
    2. You often forget how to fix it later
  4. You won’t have any more time in the schedule for the next release.
    1. You won’t have any more funding either.
    2. And you will probably forget about it
  5. Nothing is free, coupling might save you time now, but it will come at the cost of more time spent on the inevitable rewrite that coupling assures.
  6. Plan as if every programmer who will interact with your code is an idiot. Then you have the worst case taken care of. If they’re not idiots then it’ll just be that much easier to use.
  7. Comment your code as if you were going to have to pick it up and use it again in 15 years.
  8. Your code is not finished until you’ve tested it.
    1. Never assume the other guy tested his code.
    2. Never assume the test team will throughly test your code.
    3. You are the front line of the QA effort.
  9. Consistency is often more important than doing it the best way. A less than perfect coding practice that is done consistently the same way is usually better than solving the same problem in “better” ways differently each time.
    1. Don’t sacrifice maintainability and understandability in the name of the “optimal” solution
    2. Going with that, clever code is bad. Clever code means it is unclear, non-obvious, or otherwise obfuscated. The benefits almost never out weight the costs here.
  10. Try to design things so that likely coding mistakes can’t happen (e.g. don’t make the length field in a TLV include the size of the TLV header, or some jerk will not account for invalid lengths).
    1. On the rare occasions when they do, document accordingly.
  11. Debugging a piece of code is about twice as hard as writing that same code. If your code is as complex as you can manage, you’re no longer qualified to debug it.
    1. And you probably should find someone else to continue its development
    2. And maintenance
    3. And testing
  12. Time estimation is really hard…it will take longer than you think it will. Under promise and over deliver. (see rule 50)
    1. No really, even if you take this into account it will still take longer than that.
      1. Seriously…
  13. The majority of time spent on a project by developers will not be writing code, it is spent on tasks that programmers are not as good at like debugging, testing, truly understanding requirements, documenting, etc
  14. The night before its due is probably not the best time to start integrating your code in a large project.
  15. You have several options:
    1. Be amazing at your job and be an asshole
    2. Be amazing at your job and be political/nice.
    3. Be decent at your job and be political/nice.
    4. Being bad at your job and being nice will get you fired. (usually by the assholes that call you out)
    5. Being bad at your job and being an asshold will get you fired. (usually by everyone else that sees your BS)
    6. If you are amazing, it serves you best not to flaunt it, but rather let your work speak for itself.
  16. Several guys sitting around one screen trying to fix a bug is rarely productive. Share your ideas, bounce things off each other, then disperse and come up with the next solution. Sitting around watching one person work is a waste of time.
  17. White boards are around your office for a reason. Use them!
    1. If you don’t have one, ask for one.
  18. Anyone that repeatedly declares things impossible should find their way to your kill file.
  19. In programming, style is substance too. Consistent style improves code readability and makes the code more manageable in the future.
    1. Its less important that a project has the style you like than it is that a project have a consistent style that everyone uses.
    2. Don’t nitpick on minor style inconsistencies (a tab in one file instead of 4 spaces, a single brace on the wrong line). It is counter-productive and will only make you look like an ass.
  20. Laziness and incompetence are contagious.
  21. An engineering manager’s job is to do all that is required to ensure that his engineers can do their job. This usually includes keeping his engineers sheltered from politics or any other “outside world” issues, so all they have to think about is their main responsibilities….developing, testing, documenting, etc
    1. listen to and be mindful of your manager when they do decide to involve you in those things
  22. Good engineers are harder to find than most people think, if you have one, do everything you can to keep them.
    1. The same goes for good managers.
    2. Good engineers will quickly realize if they are undervalued and will not hesitate to jump ship to somewhere where they are worth more.
    3. Top talent will not be acquired without top compensation and benefits. You can’t get the best if you don’t match what your competition is willing to offer them.
    4. You get what you pay for. If you think that less skilled or unexperienced engineers will do the same job as more experienced engineers then you are very mistaken. You might pull it off for a release or two, but sooner or later the real bill will come due.
    5. The senior engineers on your team are there for a reason. Don’t hesitate to involve them in your work, you won’t regret it. Don’t hesitate to ask them questions, you’ll look stupid down the road if you don’t. Don’t hesitate to challenge their ideas. The best solution is almost always a combination from many different perspectives.
  23. If you force developers to be more accountable for the bugs they cause, then the bad programmers will spend more time fixing bugs, and less time adding more bad code to the project…(a self limiting problem).
    1. Dedicating all of the QA effort to a separate test team is a recipe for disaster.
      1. Especially when there are geographic and cultural barriers to overcome
  24. A good exercise is to make your engineers swap code with each other…either you’ll get better code out of them, or they’ll kill each other…either way it should be fun to watch.
    1. On a larger project, this will be even more beneficial as it will expose people to areas of the code base that they may have never seen before
  25. Any time you use open source code in a project, be prepared to maintain your own branch of that code. You never know when the developers will get bored and leave you hanging.
  26. Be careful how you mix your licenses. Using GPL’ed code everywhere might speed up your startup’s time to market, but it could all be for nothing if your code ends up being forced into becoming GPL. (think LGPL)
    1. If youʼre not adding much to the GPL that you’re basing your proprietary product on, then sooner or later people won’t bother paying for your code at all. You have to have something of value to add.
  27. Beware of anyone in a suit.
    1. Especially if they make you come to work in one too.
  28. The man in charge often didn’t get there by being better than everyone else; keep that in mind.
    1. That doesn’t change the fact that heʼs in charge.
  29. If you’re made responsible for something (like security) but you are not empowered to make sure it happens, then your real job is to be the person blamed when something goes wrong.
  30. Engineering’s job is to find a way to say yes; even if the request sounds (or is) stupid.
    1. Especially if it comes from a client
    2. Don’t be afraid to ask questions
    3. If the request sounds stupid try to get to the root of what they’re really trying to do, often you’ll find that they are thinking too far ahead of themselves and a simple solution exists.
    4. Saying yes to the project does not mean saying yes to unreasonable or unrealistic time lines or resource allocations. You still have to set expectations appropriately.
    5. Saying yes also does not mean keeping your opinions quiet. If you think they are going down the wrong path, tell them so, but be prepared for the fact that engineers rarely call the shots.
    6. Don’t be afraid to propose alternate solutions
  31. Keep your code for work very separate from your code for personal projects.
    1. Be careful not to use work equipment for private projects either.
    2. Keep publicly published code out of proprietary code bases, otherwise you are a lawsuit waiting to happen.
  32. Don’t work any harder than you will be rewarded for.
    1. There are many types of rewards, how you define that is entirely up to you.
    2. Don’t stay in a job if you know you can get rewarded for your work better somewhere else
    3. Especially if you do not see a upward moving career path where you are
  33. Don’t ever let your company make you do something you would not be proud of; you may have to work with them now, but you’ll have to live with yourself and your reputation for the rest of your life.
  34. If your company makes a habit of asking you to do something you’re not proud of, find a new job.
  35. Management has no idea what the customer wants.
  36. Engineering has even less idea what the customer wants.
  37. There are people out there that specialize in turning customer desires into specific technical requirements. Engage them and work with them to turn the customer’s dreams into your product’s reality.
    1. Not using those people is a recipe for disaster
    2. Rarely is a product that only your engineering department thinks is “cool” really worth something in the marketplace
      1. “Cool” is not a business case.
  38. If you don’t talk to your customers to see what will make them happy, then sooner or later someone else will.
  39. Demonstrating that your competitors suck isn’t enough to get anyone to buy your product.
  40. Don’t ship anything you’re not proud of.
    1. Even if management tells you to. If they insist, raise your concerns to someone that will hear your case.
  41. Never outsource your core competency.
  42. In general, “revolutionary” products, aren’t. Even giants such as Apple have demonstrated that being “revolutionary” can only last so long until your competitors are just as much or even more on the cutting edge as you are.
  43. It doesn’t matter how secure your product is if no-one is willing to use it.
    1. The same goes for just about any feature or aspect of your product.
  44. Chances are your customers/users are not as dumb as you think they are.
  45. “Working from home” doesn’t count against vacation time.
  46. Only listen to the boss that can fire you, the others are just useful for stopping bucks before they hit you.
  47. More people notice it when you stay late, not nearly as much when you arrive early.
    1. If you arrive early and leave early, people will still think you are shorting hours.
  48. Your best guys probably won’t waste most of their time if you gave them something more challenging to work on.
  49. Never commit to anything in emails that you’re not actually committing to, if you must, commit to it over the phone or in person with no witnesses…otherwise learn phrases like “I’ll look into that” or “we’ll see what we can do”.
  50. Under promise and over deliver. If you are given a week to do something, tell your manager that you will do your best to get it done in that time-frame, then finish and deliver it a few days early.
    1. Management never gets tired of things getting delivered ahead of schedule.
    2. Even if that schedule is more relaxed than you know you could adhere to.
  51. If its been done before its boring.
    1. Unless you need that feature to be competitive.
  52. Odds are (Haskell/Scala/Go/Erlang) won’t be as revolutionary as you think it will be…C is still alive and well and not going anywhere
    1. So is COBOL for that matter.
    2. And RPG too
    3. And the mainframe…
    4. Picking a technology to work with just because it is the current “fad” will almost always end up biting you in the ass down the road
      1. That doesn’t get you out of having to keep up with current trends. They might not be a revolution, but they might not go away either.
  53. Use the language that you are most comfortable with, even if its not a perfect fit. Its often faster to make the language fit the developer, than to make the developer fit the language. Unless this violated rule 52.4
  54. Contrary to popular belief, ad-hoc third party libraries reduce portability of your code.
    1. This does not apply to well supported and funded libraries, or ones that you license for your use.
  55. Open source code is filled with bugs.
    1. Which get fixed based on perceived importance.
  56. Closed source code is also filled with bugs.
    1. Which get fixed based on amount of funds thrown at them.
    2. Or by the desire of the company to retain that customer
    3. Or by the desire to limit potential bad press
  57. If you have a support contract, don’t be afraid to use it.
  58. If you’re not getting better, you’re getting worse.
  59. Writing a technical book is way more work than you probably think it is.
    1. But being published has its benefits, especially with your reputation around the office as well as when you apply for other jobs
      1. Especially when your company will financially reward you for it
  60. Don’t be afraid to publish your innovations as patents
    1. Especially when your company will financially reward you for it
    2. You might not get personal rights to your idea, but your name will forever be associated with it
  61. Bugs exist in the space between what a program is supposed to do and what a program actually does. There is no such thing as self documenting code. Yes the code tells me what the program does, but it can never tell me what the program is supposed to do. Comments should explain what the program is supposed to do in as much details as the code explains what it really does.
  62. Avoid commenting the stupid stuff. We all know that int x = 0 means you are initializing x to 0. Your comments should read like a summary of the code path, not a Wikipedia article describing every little detail.
  63. Always document corner cases that you are accounting for.
  64. Take an etiquette course. People do in fact notice if you handle yourself with style and even more so, when you do not.
    1. I’ve taken this one from Nonnie Owens, which was fantastic. Find a course like this or someone who already has this knowledge who will teach it to you. Trust me, you’ll thank me later.
  65. Anyone can throw around “buzz” words. Just because you can say things like “Agile”, “MVC”, “Web 2.0” and the like, if you cannot back them up with actual substance, people will see right through you.
    1. If someone is doing this, play buzzword bingo
  66. Unless you are in the small minority (and you probably know if you are), if you code in the real world like you do in college, you will probably find yourself at a major disadvantage. Academia too often pushes the “just get it done no matter how you do it before the deadline so that your code passes the autograder” mantra. Generally, instructors in academia either don’t know how to properly write software or don’t really care. Don’t let the bad habits that poor coding instruction from school pushes on you stay with you forever. There are infinitely more jobs out there for competent coders with solid CS backgrounds than there are for CS theorists that don’t know how to code properly. Keep that in mind.
  67. An instant message is better than an email. A phone call is better than an instant message. Talking to someone is person is priceless.
    1. Unless you need your communication officially recorded for some reason or another.
  68. Design is iterative. The first idea is almost never the best nor the final one. There is a reason that Walkmans with cassette tapes have been replaced by newer devices. Do not let your infatuation with a current idea let you get behind your competition, your team, or the industry.
    1. This does not only apply to your code, but also to your career in general.
  69. Don’t let your life outside of 9-5 impact your life on the clock. Doing stupid things like drinking excessively on a work night will only lead to your own downfall.
  70. Don’t let your life on the clock impact your life outside of 9-5. Sacrificing yourself for your job is rarely appreciated to the extent that is worth your suffering.
  71. Any company that asks you to solve riddles or programming problems that have tricks to them is not worth your time. A company like that is looking to see if they can fool you, and is not really interested in how you actually decompose and solve problems. Riddles like those are analogous to proving NP reductions….it is important that you know about them, but your ability to easily solve them quickly without aides has no correlation whatsoever as to how successful you will be in your job. (I prefer the Joel method)
  72. Be confident in yourself. Your attitude is one of the major factors on how you are perceived. If you don’t believe in yourself, no one else will believe in you either.
    1. From my experience, this rule also directly applies to relationships with the opposite sex outside of the office.
  73. When you interview, if you are not also interviewing the company for yourself, you are doing it wrong.
    1. Do the toothbrush test. When you meet people that want you to work with them, if you couldn’t imagine yourself brushing your teeth next to them when you wake up everyday, you probably will be unhappy working with them.
  74. Don’t take a job solely on compensation. If you are, you are doing it wrong. Money is only one component into making the right career choice.
    1. You need to think about the things that money cannot buy, especially your quality of life outside of 9-5
    2. Money cannot buy happiness, unless you buy a waverunner, no one can be anything but happy while zipping across a lake on a waverunner
  75. Don’t be afraid to use version control, that’s what its there for.
    1. Use version control properly, use meaningful commit messages. Make your version control read like a history of your code base.
  76. From time to time every rule must be broken; one of the tests of a good engineer is knowing when those times are.
    1. The best engineers know when to break the rules, but they also know how to compensate for the resulting problems (documenting more, making it an idiom, etc).
  77. Leverage your network. What you know can be just as important as who you know.
  78. Learn something new everyday. If you aren’t growing your repertoire, you aren’t helping yourself.
    1. If your company doesn’t encourage this, find a new job.
  79. If your direct management is not capable of grasping the technical aspects of your daily work, then they are not qualified to manage you.
  80. Teaching something non-technical to someone with a technical background is easier many times over than the reverse. If you are hiring someone for a QA or technical writing position but they are a horrible coder, you are setting yourself, your team, and your company up for failure
    1. From my personal experience of teaching over 4000 students software engineering, I am positive that teaching a technical person something non-technical is much much easier than teaching a non-technical person something technical. When I taught a graduate level course at Illinois, I could teach anyone with CS fundamentals testing in a matter of weeks, but teaching someone with a testing background how to code scaled on the matter of years.
    2. Anyone who argues the opposite of this rule should be in your kill file, trust me, it is for the best.
  81. Conventions are generally a good thing, but the best engineers will know when to break them. If you are working with someone that imposes conventions even when better design prevails without them, that person should also be in your kill file.
  82. Do not ever end up in a job where your technical skills are neglected so that you become a clerk. There are less qualified people out there that can do those secretarial jobs for you. Demonstrate to your management through actions that your time is better spent on things a clerk cannot do and things should fix themselves.
  83. If your manager is a clerk, find a new job.
  84. It is great to evangelize about a process, but even if it has the best intentions, developers will rebuff it due to increased overhead on them.
    1. Developers are generally lazy and set in their ways
    2. You need to demonstrate the benefits of the increased overhead before they will adopt anything new
    3. If you do all of this, but some rogue developers still ignore it, publicly shame them
    4. Remember to be political though all of this
  85. These rules are not immutable
  86. What is the big O of merge sort?
    1. if you knew the answer off the top of your head, you pass the litmus test
    2. If you had to think about the answer to that for more than 2 seconds, you should not be working with me, working for me, or managing anyone like me because you are not qualified at the most basic level. Please reevaluate your career.
    3. What is the impact of the pivot on quicksort?
      1. same rules as 86.1, except if you cannot spit it out within 30 seconds, please disassociate yourself with software immediately, it’ll save all the educated people the trouble of having to deal with your ignorance.
    4. What is the big O of radix sort on an array of integers?
      1. being able to analyze this on a whiteboard will do 1 of 2 things
        1. make you look brilliant for knowing something not many people do
        2. shut you out of a job because idiots feel threatened when they are proved wrong by things they have not bothered to educate themselves on
    5. If I say the words “visitor”, “flyweight”, “bridge”, and “memento” and you cannot correlate them instantly, you belong in my kill file.
    6. Oh you know what “singleton” is, yeah I think we all know that popcorn is the basis of cracker jacks too…..
  87. Never be afraid to go to someone who can actually make a difference. Just because that person might be your 2nd line manager or even a VP of a company, the benefits almost always outweigh the deficits.
    1. I have found that when I do this, I actually gain respect and things start changing. The fear of raising concerns is often unwarranted.
      1. If you do get dinged for doing this, you should probably change jobs
  88. Remember to be political through all of this. If your daily job involves dealing with idiots, be kind and continue on. You will serve yourself by not burning bridges (tenure in this industry often outweighs value). Vent to people that will understand and call your bluff.
  89. If you regularly walk into meetings at work and are the smartest person in the room, do yourself a favor and find a role you will be challenged in.


I’ll probably be constantly changing and improving these as I continue my career, but this is how I see it now. If you have input, I’d love to hear it in the comments below.

these are purely my opinion and not that of my employer nor anyone else