The document outlines 11 rules that all programmers should live by. The rules include: focusing on solving problems rather than technologies; prioritizing clear code over clever code; only writing necessary code; avoiding comments by using clear naming; fully understanding requirements before writing code; testing code before releasing it; learning something new daily; enjoying writing code; recognizing limited knowledge; best practices depending on context; and striving for simplicity. The author provides explanations and examples for each rule.

1. Ye Win
10/22/2015
11 Rules All Programmers
Should Live By

2. 2
11 Rules All Programmers Should Live By
I am a person who tends to live by rules.
Now granted, they are mostly rules I set for myself—but they are still rules.
I find that creating rules for myself helps me to function better, because I pre-decide things ahead
of time instead of making all kinds of decisions on the fly.

3. 3
11 Rules All Programmers Should Live By
Should I go to the gym this morning?
Well, my rule says that on Wednesdays I go to the gym and today is Wednesday, so I am going to
the gym—that settles it.
This week, as I was thinking about some of the kinds of rules I impose on myself, I thought it
might be a good idea to come up with a set of rules that I think all software developers should
live by.
Now, I’ll admit, most of these rules are more of guidelines, but anyway, here they are:

4. 4
1: Technology is how you get to the solution, it is not
THE solution
• We can get really carried away with the latest JavaScript framework—ahem, Angular—IoC
container, programming language or even operating system, but all of these things are not
actually solutions to the problems we are trying to solve as programmers, instead they are
simply tools that help us solve the problems.
• We have to be very careful not to get too crazy about a particular technology that we happen
to like or that happens to be oh so popular right now, lest we run the risk of thinking about
every problem as a nail, just because we happen to be holding a shiny hammer we just
learned about.

5. 5
2: Clever is the enemy of clear
• When writing code, we should strive to write code that is clear and easy to understand.
• Code that clearly communicates its purpose is much more valuable than code that is
obscure—no matter how clever it may be.
• It’s not always true, but in general, clever is the enemy of clear.

6. 6
2: Clever is the enemy of clear
• It’s usually true that when we write code that is “clever,” that code isn’t particularly clear.
• It’s important to remember this rule whenever we think we are doing something particularly
clever.
• Sometimes we write clever code that is also clear, but usually that is not the case.
• If you’re interested in writing clean code I highly recommend you check out The Clean Coder:
A Code of Conduct for Professional Programmers (Robert C. Martin)

7. 7
3: Only write code if you absolutely have to
• This one might seem a little contradictory, after all, isn’t our job as programmers to write
code?
Well, yes and no.
• Our jobs may involve writing code, but we should still strive to write as little of it as possible
to solve the problem we are trying to solve.
• This doesn’t mean we should make our code as compact as possible and name all our
variables using single letters of the alphabet. What it does mean is that we should try to only
write code that is actually necessary to implement the functionality that is required.

8. 8
3: Only write code if you absolutely have to
• Often it is tempting to add all kinds of cool features to our code or to make our code “robust”
and “flexible” so that it can handle all different kinds of situations. But, more often than not,
when we try to guess about what features would be useful or we try to pave the road to
solve for problems that we think might exist in the future, we are wrong.
• This extra code may not add any value, but it can still do a lot of harm. The more code there
is, the more chances for bugs and the more code that has to be maintained over time.
• Good software engineers don’t write code unless it’s absolutely necessary.
• Great software engineers delete as much code as possible.

9. 9
4: Comments are mostly evil
• I’m not a big fan of writing comments in code. I’m with Bob Martin, when he says:
– “Every time you write a comment, you should grimace and feel the failure of your ability of expression.”
• This doesn’t mean that you should never write comments, but for the most part they can be
avoided and instead you can focus on doing a better job of naming things.
• Comments should only really be written when it’s not possible to clearly communicate the
intent of a variable or method by using a name. The comment then serves an actual purpose
that could not be easily expressed in the code.
• For example, a comment could tell you that this strange order in which some operation was
occurring in the code was not a mistake, but was intentional because of a bug in the
underlying operating system.
• In general though, comments are not only evil because in many cases they are necessary, but
also because they lie.

10. 10
4: Comments are mostly evil
• Comments don’t tend to get updated with the rest of the code and this results in the
comments actually becoming dangerous, because they very well could steer you in a
completely wrong direction.
• Do you check every single comment against the code to make sure the code is actually doing
what the comment says? If so, what is the point of having the comment? If not, how can you
trust that the comment is telling you the truth?
• It’s a pickle, so it’s best to avoid it as much as possible.

11. 11
5: Always know what your code is supposed to do
before you start writing it
• It seems obvious, but it isn’t.
• How many times have you sat down to write code without fully understanding what the code
you were writing was actually supposed to do?
• I’ve done it more times than I’d like to admit, so this is a rule that I need to read often.
• Practicing test driven development (TDD) can help here, because you literally have to know
what the code is going to do before you write it, but it still doesn’t stop you from creating the
wrong thing, so it’s still important to make sure you absolutely, 100% understand the
requirements of the feature or functionality you are building before you build it.

12. 12
6: Test your sh—code before you ship it
• Don’t just toss your code over the wall and have QA pound on it only to send it back to you
so that you can waste a bunch of everyone’s time with unnecessary bug reports and
resolutions.
• Instead, take a few minutes to run through the test scenarios yourself, before you call your
code done.
• Sure, you won’t catch every bug before you pass your work on to QA, but you’ll at least catch
some of the stupid and embarrassing mistakes that we all make from time-to-time.
• Too many software developers think that it is only QA’s job to test their stuff. It’s simply not
true. Quality is everyone’s responsibility.

13. 13
7: Learn something new every day
• If you didn’t learn something new today, you just made backwards progress, because I can
guarantee you forgot something.
• It doesn’t take a lot of time to learn something new each and every day.
• Try spending just 15 minutes or so reading a book
• The little advances you make each and every day add up over time and will greatly shape
your future. But, you have to start investing now if you want to reap the rewards later.
• Besides, today technology is changing so rapidly that if you aren’t continually improving your
skills and learning new ones, you are going to be left behind very quickly.

14. 14
8: Writing code is fun
• That’s right. You probably didn’t get into this profession just because it pays well.
• I mean, there is nothing wrong with picking a job that pays well, but doctor or lawyer would have
probably been a better choice.
• Most likely you became a software developer, because you love writing code. So, don’t forget that
you are doing what you love.
• Writing code is a lot of fun. I wish I could write more code.
• I’m usually too busy keeping this business going to spend much time writing code these days, which
is one of the reasons why I so clearly remember how much fun it is.
• Perhaps you forgot that writing code is fun. Perhaps it’s time to remember how much fun it is
again, by starting a side project or just changing your mindset and realizing that you get to write
code and you are even paid for it. (Hopefully)
Refer - http://founderdating.com/whats-in-a-side-project/

15. 15
9: You can’t know it all
• As much as you learn, there is still going to be a lot you don’t know.
• It’s important to realize this because you can drive yourself nuts trying to know everything.
• It’s OK to not have all the answers.
• It’s OK to ask for help or to speak up when you don’t understand something.
• My point is, don’t get caught up in trying to learn it all, when that is an impossible task.
Instead, focus on learning what you need to know and building the skills that enable you to
learn things quickly.

16. 16
10: Best practices are context dependent
• Is test-driven development, the best way to write code?
• Should we always pair program?
• Are you a scrub if you don’t use IoC containers?
• The answer to all of these questions is “it depends.”
• It depends on the context.
• People will try to shove best practices down your throat and they’ll try to tell you that they
always apply—that you should always do this or that—but, it’s simply not true.
• I follow a lot of best practices when I am writing code, but I also conditionally don’t follow
them as well.

17. 17
11: Always strive to simplify
• All problems can be broken down.
• The most elegant solutions are often the most simple ones.
• But, simplicity doesn’t come easy. It takes work to make things simple.
• The purpose of this blog is to take some of the complexities of software development, and
life in general, and make them simple.
• Believe me, this isn’t an easy task.
• Any fool can create a complex solution to a problem. It takes extra effort and care to refine a
solution to make it simple, but still correct.
• Take the time. Put forth the effort. Strive for simplicity.

18. 18
Thank You!!

19. 18
References
• Soft Skills: The software developer's life manual 1st Edition (John
Sonmez)
http://www.amazon.com/Soft-Skills-software-developers-manual/dp/1617292397