2. Skill you MUST have in order to be a good
programmer
Characteristics:
◦ Hard to acquire
◦ Long lasting
3. Skill that you don't necessarily need to have
to succeed as a programmer, but is a skill
you gained fortuitously
Characteristics:
◦ Relatively easy to obtain
◦ In technology, accidental skills have short half lives
Brown and Thomas, New Culture of Learning, 5 years
Eric Bloom, Manager Mechanics, 2 years
4. Is knowledge of a programming language
essential or accidental?
Steve McConnell, Code Complete
◦ “Accidental”
As a C# developer, if your manager suddenly
decided to develop products in Python, how
long would it take complete your first simple
task?
◦ If you’re a senior developer, not too long.
5. They tend to be things that you already know
you should do, but don’t (for one reason or
another)
Acquired more by repetition/habit rather than
classroom/reading
Examples: Good design, Writing code that’s
easy to read, Limiting bugs, Unit tests,
Managing complexity
6. It’s the Essential Skills that separate the good
from the bad.
But why should we care?
7. “A great lathe operator commands several
times the wage of an average lathe operator,
but a great writer of software code is worth
10,000 times the price of an average software
writer.” Bill Gates
"One top-notch engineer is worth 300 times
or more than the average." Alan Eustace,
Google vice president of engineering
Of course they’re exaggerating
8. Which of the following do you spend most of
your time doing?
A. Trying to understand previous code
B. Debugging
C. Writing new features
D. Putting out fires
E. Planning/Designing the solution to your
task
10. Does it work?
Does it need to be read too many times to
understand?
Is more time spent debugging than the
original coding time?
Is it difficult to add features without creating
spaghetti?
11. Other than “it works”, what is the most
important rule to follow when coding?
Manage Complexity
12. Edsger W. Dijkstra, The Humble Programmer
(1972)
“The competent programmer is fully aware of the
strictly limited size of his own skull
and among other things he avoids clever tricks like
the plague”
“There is no simple problem that a bad
programmer can't make complex.“
◦ uncredited
"A simple solution to a complex problem is about
as clever as anyone can get.“
◦ uncredited
13. Say that again?
“The competent programmer is fully aware of
the strictly limited size of his own skull”
We all have the problem of limited brain
capacity. No shame in admitting that.
So write code that acknowledges that our
brains are limited.
14. If you see complexity in your work, identify
whether it is Accidental Complexity or Essential
Complexity.
Essential complexity is caused by the problem to
be solved, and nothing can remove it. If your
product design group really wants a screen with
2 charts, a map, big block text, summary table,
and numbered annotations on one page, and a
virtual helicopter that floats over the map, there’s
nothing you could do about that.
Accidental complexity relates to problems that
we create on our own (usually because of bad
design) and which can be fixed
15.
16. Robots can write code that is more efficient
than what humans can write.
But robots still can’t write code that is easily
readable by humans.
17. On one end, you don’t survive in the industry
for long.
On the other end, only a few people live there
thanks to a God-given talent.
Most of us are somewhere in the middle.
Fortunately there are some simple things we
could all do to move ourselves closer to the
right.
Not Good Great
18. “The proper use of comments is to
compensate for our failure to express
ourselves in code.” Robert Martin, Clean Code
But that quote only applies to
implementation.
For interfaces, proper comments are crucial.
Before finishing your interface, ask “Does a
programmer need to see the implementation
to know what to expect?”
◦ Add more comments if the answer is Yes
19. Many times, detailed comments on a
parameter or property aren’t necessary. But if
something is ambiguous, write clarifying
comments.
20. What is “ImageSource”? Is it a url? Is it a
serialized stream of the image?
You don’t know unless you actually run the
code or look at the implementation.
Don’t make programmers do that.
21. Don’t make programmers ask “What’s the
difference?” “Which one do I use?”
22. Again, don’t make programmers ask “Which
one do I use?”
23. Short Methods
Limit Class sizes (<500 lines suggested)
If you trigger a Code Analysis
“CA1506:AvoidExcessiveClassCoupling" error,
do not suppress it with "As Designed“
Unit Tests!
◦ Resist the temptation to skip.
◦ I know, it takes 10 minutes to do your production
code, but unit tests requires another 3 hours of
coding.
◦ That’s why being good at unit testing is an essential
24. CurrentSearchCriteriaJson isn’t used
anywhere in the immediate code.
We don’t know if that line is a mistake.
I can’t find references to it. Is it safe to
remove that line?
25. Have well-documented interfaces.
Short Methods
Limit Class sizes (<500 lines suggested)
If you trigger a Code Analysis
"CA1506:AvoidExcessiveClassCoupling" error,
do not suppress it with "As Designed“
Unit Tests.
Avoid relying on states.
26. This is how we all probably started our
programming careers.
1. Put on blindfolds
38. Perhaps about 15% of your time should be
spent writing the production code. (Step #5)
That’s why you might need to allocate 6
hours for a task that only needs 1 hour of
coding.
Spend more time talking to other people, less
time working alone.
39. What the discussion phase (step #2) should
NOT be
Instead, formulate an alternative solution
and decide which is better.
40. Why is an alternative solution IMPORTANT?
“Study after study shows that the very best
designers produce structures that are faster,
smaller, simpler, clearer, and produced with
less effort. The differences between the great
and the average approach an order of
magnitude.”
Frederick Brooks, No Silver Bullet, 1986
Considering two solutions ensures you won’t
pick the solution that is 10x worse than the
best solution
41. “Good code is short, simple, and symmetrical
- the challenge is figuring out how to get
there.”
◦ Sean Parent, Adobe mobile digital architect
42. Write well-documented interfaces
Short Methods
Limit Class sizes (<500 lines suggested)
If you trigger a Code Analysis
"CA1506:AvoidExcessiveClassCoupling" error,
do not suppress it with "As Designed“
Unit Tests!
Avoid relying on states.
Consider an alternative solution
43. The development of essential skills makes it
more likely that your next 10 years will really
be 10 years of experience, not one year
experienced 10 times.
◦ Steve McConnell, author of Code Complete
