Week 38 of 2017, 9th post of the 4th year (May 2017 - May 2018)

Here is a summary from another book about the career aspect of programming. The post does not have any watery stuff, I tried to write down just the key ideas, pure and concentrated.

  • use TDD

In almost every book I read, the authors either advice to use TDD or talk about it a lot

  • Saying no to false hopes is professional

It means when a manager asks you when you’re gonna finish something and you know you can’t do it in time

  • Estimate is not a number but rather a distortion
  • It’s best to give estimates based on calculations of probabilities
  • Have three estimates - the normal one, the worst case and the best case

Estimating is hard, it sounds like a good piece of advice

  • Programming has lots of situations with overworking
  • Overworking is not productive
  • Do not refuse to help people fresh prospective helps
  • An idea of kata - an etude for programmers

This one is probably the most interesting advice from the book. The kata is, basically, just some programming exercise that you should do to warm yourself up a bit for more serious job. You should master it and do it as fast as you can.

I, actually, never thought as anything like that. I personally don’t know if I’d like to try it out or to adopt it, because, in my opinion, since there’s plenty of code a one has to write every day, there’s no need in some training exercise to warm yourself up.

You should just do it by working.

  • Write katas together with other programmers
  • It’s not your employees responsibility to pay for you to sharpen the skills, you should do it in your free time
  • Write acceptance tests
  • Unit tests are the lowest written for programmers, acceptance tests are written to explain how the system would behave and are for the business
  • If a business meeting gets boring it’s better to try to leave without being rude
  • If there’s an argument and if it’s not possible to resolve it within a short period of time, then you shouldn’t waste the time arguing and you should go get some data to find out the right thing. If it’s not possible, you should toss a coin to resolve it
  • Do some physical activity to reset your brain for writing software
  • Also it’s good to do a meeting to ask every team member about it to get better perspective
  • Avoid the stress by managing commitments, writing clean code and staying calm
  • Deal with stress by staying calm, following your discipline, communicating and getting help
  • Programming is about working with others
  • Schools don’t teach how to be a good programmer, ideally, it’s achievable with mentorship
511 words in the post