Pithy lessons from 15 years of software project work.
Work somewhere or do something you can be passionate about. Passion will get you to work early and eager, then keep you focused for years. There is no substitute for the never ending well of tenacity and grit that comes from really caring about your work. This attitude is infectious and success will flow easily when you have it directed properly.
Clinical professionalism is important as well. Your ability to make cold objective decisions is inversely proportional to how much you care about an outcome. Everyone is subject to this on some level. Exercise your self awareness and seek external advice from professionals you trust when possible. This is a challenging dichotomy for many of us, because it becomes harder to be successful in a domains we don’t care about, and in domains we care about we may become too emotionally invested at times to make the best decisions.
For career advancement, raw technical ability is not nearly as important as charisma and being liked and respected by your peers. Technical ability will bolster these stats but it is no replacement.
When building something new, capture the initiative early and maintain it. Show significant visual progress early and often. I love demonstrating and rapidly building functional proof of concept applications. These will do more communicating in 30 seconds than 30 years of PowerPoint presentations or static interface mockups.
Never listen to people who tell you a project is too ambitious or impossible. Try to build it, you’ll be amazed at what you can accomplish in the time you would have wasted trying to convince the timid.
The places you least want to look are more likely to contain the solutions to your longest lived problems.
Continually reassess your assumptions from first principles. Constraints may no longer hold.
### Architecture & Refactoring
No set of requirements will ever be complete or correctly weighted at the start. Focus on providing a flexible architecture that can adapt to changes without becoming a mess throughout the Software Development Life Cycle. Use discipline and continue to follow conventions rather than resorting to hacks when features or requirements change repeatedly.
At the beginning of a project, too much time and effort is often spent on requirements that end up not mattering. Near the end of the project there is often not enough time to give the requirements and features that really do matter the attention they deserve. Agile development does help with this to some degree. Get the core functionality working quickly and into the hands of users so you don’t end up exasperating this problem.
Fancy ORM is great until you need to do something a little weird.
When first being exposed to a legacy codebase you are biased towards a total replacement because you do not understand the details. When you are familiar with a legacy codebase you are biased against replacement because you now understand the details. Be aware of, and counter these biases in yourself and your team.
If you are working in an existing project with a long history, follow the conventions unless you plan on refactoring the whole project. When you encounter bizarre complexity it’s often a sign you don’t understand the problem. It’s important to keep notes on these things because by the time you understand the project as a whole you may be too indoctrinated in its constraints and conventions to remember what it was you wanted to fix in the first place.
When writing an app for an organization to be used by employees get a big picture from the managers and then interview the users. Make sure to observe the users during crunch time and the most time consuming aspects of their existing processes will jump out at you. Make sure to sit with both top performers and poor performers. Managers will push you towards the best employees but it’s the poor performers who are having issues with the process. Usability insights will come from the people having trouble not from the people doing well.
Smarter people have a higher tolerance for complexity. This can lead to huge problems if the people maintaining the system are less capable and don’t understand the foundational principles behind the architecture. Involve these people in your architecture planning meetings to ensure they either can understand or you should dial back the ambition.
### Navigating Bureaucracy
Develop relationships outside your group. Demonstrate competence and broad ability. Stick up for people you know are on the right track. Raw technical ability will get you nowhere without trust and shared understanding from people in key positions.
Organizations are subject to entropy. Bureaucracy will expand and atrophy until it can barely function. Disruption and reversal is possible only with a large external source of energy. Disruption of existing order will always be painful.
For ambitious projects: Find good people and give them latitude. Shield them from the bureaucracy. Refine and adapt your project to your processes after you have something tangible but don’t wait too long! When you have a compelling demo show it to people with the power to protect it until it can take root. The wrong person who knows too early will kill it.
Shared best practices are critical, adherence to policy must be weighted against time, short and long term goals of the project, the big picture, and goals of the organization. Great developers and leaders know how to balance these within the scope of their authority. This balance is different for every team, project, and organization.
You must be aligned with power in an organization in order for your initiative to succeed. Trying to act without it will result in being caught up by endless time consuming policy transgressions. Acting while in alignment feels like policy doesn’t exist. The winds will shift rapidly but you can often predict it if you are cognizant of how outside forces influence the organization.
Policy is an impersonal method of control which exists ostensibly to protect the organization and enforce standardization. If necessary it can be easily changed. In practice it is a blunt tool, selectively enforced, and internally inconsistent. Pointing this out won’t help when it’s being used against you, because it means you have already lost the mandate of heaven.
Package your initiative as an answer to meeting broader goals set by executives.
You must make hard decisions which will anger people you like. Before doing so, thoroughly understand the potential for fallout and be prepared to argue your case and lose.
Don’t allow yourself to be responsible for things over which you have no control.
### still here?
I’m looking for a leadership role on an ambitious team who is anticipating how current trends and technology will shape the world. Let’s manifest the future!
I work best in domains I am passionate, for leaders with ambitious vision, and in organizations where top performers have latitude.
I like working on projects simultaneously, where I am creating and developing demos into full featured products.
I’m extra interested in VR, WebXR, WebGPU, Web3, distributed computing, crypto, decentralized services and protocols, computational physics, Open Source, entrepreneurship, aerospace, and rocking the boat.