Be a Better Developer

1
Be a Better Developer Schematic Technology
Summit September 25, 2008
2
Software Development is an Art
3
Dont prescribe your glasses for someone else.
4
Are you a better developer than you were six
months ago?
5
Good is the Enemy of Great
6
Know Thyself
7
Know Thyself

• Know your strengths and stick to them
• Know your weaknesses and your faults
• Resist the urge to create your own language
• Challenge yourself but dont risk your project

8
Be Committed
9
Be Committed

• Developers are highly focused
• Developers are rarely well-rounded
• Be intentional about what youre doing and why
• Balance your professional and personal life
• The best developers find a way to sustain balance
  and avoid burnout

10
Care about your Craft
11
"Any fool can write code that a computer can
understand. Good programmers write code that
humans can understand. - Martin Fowler
12
Care about your Craft

• Take pride in how your code looks
• Code style priorities should be (in order)
• Accurately represent logical structure
• Consistency
• Readability
• Withstand Modifications
• Be careful not to get caught in Religious Wars
  about code formatting
• Sign your work
• Push for self-documenting code and good code
  commenting

13
Instead of
if(d.m 1 ((d.y 400) 0 ((d.y 4)
0 (d.y 100) ! 0))) d.n 29
14
Use
/ Determine if the given year is a leap
year. The Gregorian calendar rule states that
a leap year occurs every fourth year, except
every 100 years, except every 400 years.
_at_param year Four digit year to be tested.
_at_return true if given year is a leap year.
/ private function isLeapYear(yearuint)Boolean
var isDivisibleBy4Boolean (year 4)
0 var isDivisibleBy100Boolean (year
100) 0 var isDivisibleBy400Boolean
(year 400) 0 return isDivisibleBy400
(isDivisibleBy4 ! isDivisibleBy100) if(da
te.month Month.FEBRUARY isLeapYear(date.year
)) date.numberOfDaysInMonth 29
15
Dont Live with Broken Windows
16
(No Transcript)
17
(No Transcript)
18
Software Entropy

• Defines the measure of disorder in software
  systems
• Always increases or possibly remains unchanged
• A computer system that is used will be modified
• When a system is modified its complexity will
  increase
• Can increase the Total Cost of Ownership
• Decreases Maintainability

19
Ask Questions
20
Ask Questions

• Why are we doing it this way?
• Is there an easier or better way?
• Is this on target with the project requirements?
• What problems could result from this?
• How does my work fit into the big picture?

21
Keep it Simple
22
Everything should be made as simple as possible,
but not simpler. - Albert Einstein
23
Keep it Simple

• Simplicity is a core principal of Extreme
  Programming
• Only design for real requirements
• Never add functionality before it is scheduled
• Only 10 of that extra stuff will ever get used,
  so you are wasting 90 of your time.
• Keeping a design simple is hard work

24
Seek Feedback
25
Seek Feedback

• The people that work closely with you are the
  best judge of your abilities
• Peer Reviews
• Seek out people you trust and tell them to be
  honest
• Take action based on the feedback
• Your critics are never 100 wrong
• Debate is healthy if both sides are open to
  change

26
Play Nice
27
people who are great at something are not so
much convinced of their own greatness as
mystified at why everyone else seems so
incompetent. - Paul Graham
28
Play Nice

• Share ideas
• Know your role within the team
• Give constructive criticism
• Youre never 100 right
• Be specific with your feedback
• Dont make it personal
• What do your colleagues think of you?

29
Embrace Refactoring
30
Embrace Refactoring

• Only build what is needed at that point in time
• Refactor when the requirements change
• Refactor to reduce complexity when possible
• Watch for Code Smells and Code Stenches
• Use Unit Tests and Test Harnesses to make sure
  you dont break anything
• Refactor after each code review

31
Communicate Explicitly
32
Communicate Explicitly

• The best ideas are worthless if they cant be
  communicated
• Use email first (e-mail is forever)
• CC anyone that might need to be included in the
  conversation
• Be cautious of hallway conversations
• Keep your audience in mind
• Be available and responsive

33
Pretty Good
There once was a pretty good studentWho sat in a
pretty good classAnd was taught by a pretty good
teacherWho always let pretty good pass.
34
He wasnt terrific at reading, He wasnt a
whiz-bang at math, But for him, education was
leading Straight down a pretty good path.
35
He didnt find school too exciting, But he wanted
to do pretty well, And he did have some trouble
with writing Since nobody taught him to spell.
36
When doing arithmetic problems, Pretty good was
regarded as fine. 55 neednt always add up to be
10 A pretty good answer was 9.
37
The pretty good class that he sat in Was part of
a pretty good school, And the student was not an
exception On the contrary, he was the rule.
38
The pretty good school that he went to Was there
in a pretty good town, And nobody there seemed to
notice He could not tell a verb from a noun.
39
The pretty good student in fact was Part of a
pretty good mob. And the first time he knew what
he lacked was When he looked for a pretty good
job.
40
It was then, when he sought a position, He
discovered that life could be tough, And he soon
had a sneaking suspicion Pretty good might not be
good enough.
41
The pretty good town in our story Was part of a
pretty good state Which had pretty good
aspirations And prayed for a pretty good fate.
42
There once was a pretty good nation Pretty proud
of the greatness it had, Which learned much too
late, If you want to be great, Pretty good is, in
fact, pretty bad. - Charles Osgood
43
Suggested Reading
44
Thank You