Wednesday, February 7, 2018

Lessons Learned After a Decade in Software Development

  • Your first year or two will probably be spent learning what they didn't teach you in college.
  • It is up to you to educate yourself.
  • If you want to be great, you must spend at least a portion of your free time on self-improvement.
  • Most of the requirements you read will suck.
  • To users and non-technical team members, the user interface is the software.
  • Most of the bug reports you read will suck.
  • Demand that bugs have clear problem statements and reproduction steps.
  • In most cases, time spent fixing bugs can't be estimated. It gets fixed when it gets fixed.
  • Not every task is a programming puzzle or homework assignment. The answer is often a google search away.
  • Clean code is important, but product stability is more important. Don't refactor functioning code unless you have a good reason to touch it.
  • We are in the business of specificity. Learn to be detail-oriented.
  • Communication skills are sorely lacking in our field.
  • Strong communication often leads to less development time and better software. The opposite is also true.
  • Probably half of the comments in your codebase are cruft. Most are unnecessary. Others are outright lies.
  • Comments should be as close to the code they're explaining as possible.
  • Regarding date/time data: Knowing the date and time but not the timezone is basically useless.
  • Trying to do everything yourself and be a "hero" is a hole you dig for yourself.
  • You will rarely (if ever) encounter a "full stack developer". Almost no one excels at everything.
  • Actually design things before you build them. This helps you address problems early. It also makes work easier to delegate.
  • Requirements are the "what" and design is the "how". Additionally, the "how" at your current layer of abstraction is the "what" of the layer beneath it.
  • If you can't explain what a software component (function/class/layer) does in a sentence or two, then you don't need it.
  • Modeling techniques (UML, flowcharts, etc.) are useful when designing new systems, and can also be useful when analyzing and documenting existing systems.
  • Models should be looked at as general guidelines and/or communication tools, not infallible proclamations. "Essentially, all models are wrong, but some are useful." -George E. P. Box
  • The intent of code reviews is to maintain product/codebase stability and keep other developers in the loop as to how the software has changed, not to shame novice developers or pore over minutiae.
  • Team members who resist discussing their work are problematic.
  • Team members who resist best practices or new knowledge are problematic.
  • If most or all of your teammates are problematic, seek new employment.
  • It is up to you to educate your team (if you want them to be good).
  • Meetings are a necessary evil.
  • If it's your meeting, prepare an agenda before scheduling it.
  • The Agile Manifesto is written in a way that deceives the ignorant.
  • Agile is about promoting communication and collaboration. It is not about developing so fast and sloppily as to guarantee failure.
  • Likewise, the point of Scrum is to not bite off more than you can chew in a particular sprint.
  • If you don't call management on their bullshit, no one will.