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.