On luck and gumption

In our industry, gumption is what gets us to try new things, experiment, and build new products. Sometimes, it means trying new programming languages or frameworks with nothing else to explain the decision than your gut feeling. Sometimes, it means ignoring the prevailing management methodology to run your team as you think it should. So when opportunity knocks, have the gumption to answer.

The Toxic Clique

Working with the same group of people for 20 years is probably as bad for your creativity as working on the same project for the same company as long. Your skills stagnate, your ideas become inbred, your work becomes outdated, and your growth becomes limited by the Clique that helped you earlier in your career.

Why don’t they tell you that in the instructions?

The nature of our jobs as software engineers is such that we must deal with externalities. Hardware will crash. Services will auto-scale up and down. Garbage collection will occur. Humans will make mistakes and use our software in ways we did not anticipate. Someone will write configuration instructions for you on how to setup your dev environment, and they might not apply perfectly to your setup.

Tools of the craft

Developers should feel empowered to configure their environment and development tools to their liking and contribute to the shared team standard. They should know the libraries they picked and why they picked them. They should be able to articulate why they like one programming language over another. As part of their job, each developer should be able to state clearly and in actionable terms how they’d like to work.

On elephant graveyards

An elephant graveyard, when applied to a corporate setting, is a team, company, or some other set of conditions in which otherwise bright engineers are forced into positions or assignments where there is no hope for future career growth. In this post, I hope to define the conditions that must be present for an elephant graveyard to form, how to detect them, and how to navigate them.

What does a Chief Software Architect do?

For many years I couldn’t understand what software architects do. Early in my career, I thought they were useless. As a young developer, I felt that I could do the job of a business analyst, software architect, and developer all at the same time. Now, seventeen years into my post-college career I am one myself. I am trying to learn what it means to be a good software architect, and I hope to be one myself.