0%

The Pragmatic Programmer - Chapter 1

Posted on In

Chapter 1 A pragmatic strategy

Topic 1: It's your life

Many developers are frustrated and have lots of complaints about technology has passed them by, their team sucks, etc…

Why can't you change it?

Topic 2: The cat ate my source code

Even the best projects can have mistakes. These things happen, and we try to deal with them as professionally as we can. We must own up to our shortcomings - our ignorance and our mistakes.

  • Trust in a team is absolutely essential for creativity and collaboration. In a healthy environment, you can safely speak your mind, present your ideas, and rely on your team members who can in turn rely on you.
  • When you accept the responsibility for an outcome, you should expect to be held accountable for it. When you make a mistake, admit it honestly and try to offer options.
  • Don't blame on someone or something else, or make up an excuse. Any of these may play a role, but it's up to you to provide solutions, not excuses.
  • If there was a risk that the vendor wouldn't come through for you, you should have had a contingency plan.If your mass storage melts, and you don't have a backup, it's your fault.
  • Before approaching to anyone to tell them why something is not working, stop and listen to yourself. Talk to the rubber duck on your monitor: does your excuse sound reasonable or stupid? How's it going to sound to your boss?
  • Instead of excuses, provide options. Don't say it can't be done, explain what can be done to salvage the situation.
    • Does code have to be deleted?
    • Do you need to spend time prototyping to determine the best way to proceed?
    • Do you need to introduce better testing or automation?
    • Do you need other people to help?
    • Do you need to spend more time with the users?
    • Do you need to learn some technique in greater depth? Would a book or a course help?
  • Try not to flush out the lame excuses before voicing them aloud. If you must, tell your cat first.
  • When you find yourself saying "I don't know", be sure to follow it up with "but I'll find out." It's a great way to admit what you don't know, but then take responsibility like a pro.

Topic 3: Software entropy

  • A broken window can turn a clean intact inhabited building into a smashed and abandoned derelict very quickly.
  • Don't live with broken window, fix them as soon as it's discovered. If you don't have enough time, board it up.
  • Don't cause collateral damage just because there's a crisis of some sort. One broken window is one too many.

Topic 4: Stone soup and boiled frogs

  • Start-up fatigue: you may be in a situation where you know what needs to be done, and you know you are right. But ask permission to tackle the thing and you will be met with delays and blank stares. People will form committees, budgets will need approval and things will get complicated. Everyone will guard their own resources.
  • People find it easier to join an ongoing success.
  • It's often the accumulation of small things that breaks morale and teams.

Topic 5: Good-enough software

  • It's equally unprofessional to promise impossible time scales and to cut basic engineering corners to meet a deadline
  • Don't spoil a perfectly good program by over-embellishment and over-refinement. Move on, and let your code stand in its own right for a while.

Topic 6: Your knowledge portfolio

  • Your knowledge and experience are your most important day-to-day professional assets. Unfortunately, they are expiring assets.
  • Your ability to learn new things is your most important strategic asset.
    • Invest regularly - you must invest in your knowledge portfolio regularly even if it's just a small amount. The habit is as important as the sums, so plan to use a consistent time and place, away from interruptions.
      • Learn at least one new language every year
      • Read a technical book each month
      • Read non-technical books too
      • Take classes
      • Participate in local user groups and meetups, actively participate
      • Experiment with different environments
      • Stay current
    • Diversify - The more technologies you are comfortable with, the better you will be to adjust to change. And don't forget all the other skills you need, including non-technical areas.
    • Manage risk - Don't put all your technical eggs in one basket
    • Buy low, sell high
    • Review and re-balance - This is a very dynamic industry, maybe the technology you started investing is already stone cold by now, maybe you need to brush up on the database technology you haven't used in a while.
  • The process of learning will expand your thinking, opening you to new possibilities and new ways of doing things.
  • If you can't find answer yourself, find out who can.
  • All of this reading and researching takes time, so you need to plan ahead. Always have something to read in an otherwise dead moment. Time spent waiting for doctors and dentists can be a great opportunity to catch up on your reading.
  • Ask "why" five times.
    • Who does the benefit?
    • What's the context?
    • When or where would this work?
    • Why is this a problem?
  • If you are doing very detailed implementation and coding, read a book on design and architecture. If you are doing high-level design, read a book on coding techniques

Topic 7: Communicate

  • A large part of our day is spent communicating, so we need to do it well.
  • Treat English as just another programming language.
  • The meaning of your communication is the response you get.
  • Plan what you want to say - ask yourself "does this communicate what I want to express to my audience in a way that works for them?"
  • Make what you're saying relevant in time, as well as in content. Sometimes all it takes is the simple question: "Is this a good time to talk about…?"
  • Make it look good, don't just concentrate solely on content. Use markdown for example.
  • We often find that the documents end up being less important than the process we go thru to produce them. If possible, involve your readers with early drafts of your document.
  • Be a listener
  • Keep people informed makes them far more forgiving of the occasional slip, and makes them feel that you haven't forgotten them.
  • We want to apply all of our pragmatic principles to documentation as well as to code
  • SUMMARY
    • Know what you want to say.
    • Know your audience.
    • Choose your moment.
    • Choose a style.
    • Make it look good.
    • Involve your audience.
    • Be a listener.
    • Get back to people.
    • Keep code and documentation together.