Have your read David Thomas and Andrew Hunt’s great book, The Pragmatic Programmer? This book is an awesome compilation of years of knowledge and experience from the hands of experts in software engineering.

If you haven’t read it, I highly encourage you to do it. The impression I’ve had on this book is like talking to good ol’ paps (or, in my case, good ol’ mama) and getting life advice. But in this case software life advice. The parts they don’t teach you in college.

Bringing Pragmatic Shorts all the way up to your door

This is my first chapter of Pragmatic Shorts, a cheat-sheet like space with a point like summary of the parts that I’ve considered most relevant in my day to day job as a Software Development Engineer.

Have you ever seen Adam Savage’s or Simone Giertz’s workshops? They’re filled of organized tools. Boxes of cubes, boxes of screwdrivers, boxes of wrenches, wires, screws, etc. Picture each of these shorts as one of those boxes with composed by an specific set of tools for your software workshop 🙂

Note: This is not a shortcut to not read the book, it’s way more fulfilling and you’ll have a good time if you actually read it!

A Pragmatic Philosophy

Picture this first chapter as a big, general, set of mental models to address your every day tasks as a person that works in the software development filed, applying for long, middle and short term.

Following the mechanic analogy, picture this a a set of wrenches

• Software development is close to the top of any list of careers where you have control
• Have agency – Try to fix your environment, but don’t try forever
• Take ownership of your career, your advancement, learning, your project and responsibility
• Team trust, both sides need to be comfortable relying on each other
• Provide options, don’t make lame excuses – Don’t say it can’t be done, explain what can be done, is up to you to provide something rather than excuses, but also you have the right to say no to an impossible situation
• Don’t live with broken windows – Ignoring a broken situation (bad designs, poor code, wrong decisions) reinforces other broken situations in a vicious spiral. Fix one as soon as you discover it, there is no time later.
• Never cause collateral damage just because there is a crisis of some sort. Priority is to put out the fire, but first asses the situation.
• Be a catalyst for change – Thrust me, search for the Rock soup story 😉
• Remember the big picture – Most software disasters start out too small to notice, put a frog in boiling water and it will jump the hell out, but heat it up gradually and you’ll have a frog soup, people lose the will to fight entropy because no one else cares. Have awareness
• Discipline to make code that is good enough for users, maintainers and your peace of mind, don’t overkill nor write poor code, let the users decide you’ve produced good enough for their needs.
• Make quality a requirement – The scope and quality should be discussed as part of the requirements.
• Many users will prefer a few rough edges than wait a year for the perfect version, give them something to play early.
• Hard work is ruined if you don’t know when to stop, don’t look for perfection
• Your knowledge and experience are your most important day-to-day professional assets, and they expire quickly, as your knowledge declines so does your value to your company/client. Your ability to learn is your most strategic asset.
• Invest regularly in your knowledge portfolio:
  • Make it a habit to invest → learn even a small amount, but consistent in time
  • Diversity succeeds in the long term → the more you know the greater your value, technology changes fast
  • Balance between risk and conservative investment → Don’t put all your technical eggs in ONE basket
  • Buy low, sell high → Learning an emergent technology before it gets popular can payoff later
  • Review and adjust periodically → Hot technology today may become stone cold tomorrow
• Some good goals
  • Learn a new language every year
  • Read a technical book per month
  • Read non technical books, computers are used by people that you need to satisfy
  • Take classes
  • Participate in user groups and meetings, isolation can be lethal
  • Experiment different environments (ex. how about coding with no mouse for a week?)
  • Stay current, read from other things than what your current project is about
• Someone asked you about a technology you don’t know nothing? Don’t let it stop there, take it as a personal challenge!
• Critically analyze what you read and hear – Be critical to your knowledge portfolio, don’t let media or a vendor hype lead you to a dogma, head first.
  • Ask the 5 whys
  • Who is this benefiting? (The monkey dance’s for money, Costarrican saying)
  • When/where will this work?
  • Why is this a problem?
• English is just another programming language – It doesn’t matter if you have the best ideas and finest code, it does nothing unless you can communicate it
• Know and understand the needs, interests and capabilities of your audience, the meaning of your communication is the response you get
• It’s both what you say and the way you say it –
  • Work out EXACTLY what you want to say, plan it and ask, is this communicating what I want to express?
  • Choose the proper moment and style to communicate, then make it look good
  • Involve your audience in early drafts, then get their feedback
  • Listen to people so that they listen to you, encourage to ask questions or ask to restate the discussion in their own words
  • Always get back at people, don’t ghost even if you’re going to say “I’ll come back to you later”.
• The more effective is your communication, the more influential you are.
• Built documentation in, don’t bold on – Make it easier by not duplicating effort or wasting time, keep it close at hand. Let the code say it for you, then if you need to, discuss why something is done or the purpose. DRY