Try to feel inspired, not envious

Dear new developer,

I struggle with envy. I find one kind particularly insidious. It’s the envy I have of someone I know online. I’ll see someone younger than me, or less experienced than I am, or less knowledgeable than me. But they somehow have 10x the Twitter followers, or have been asked to headline conferences, or have written more popular books.

In my darker moments, I see them and think “why them? what did they do to deserve such fame?” I’m not proud of these thoughts, but I definitely have them.

While all my emotions are valid, this envy isn’t productive. It isn’t even realistic. Why?

Do you ever curate your online persona? I certainly do (confessions of ugly envy notwithstanding). I’m certain that these internet famous people do as well. This means that I don’t know where they actually are in terms of happiness, success or fame. I know what they choose to tell me and what I can infer. But I don’t know what other aspects of their life are like.

Second, suppose I do find out they are living a tremendous life, with no issues. Maybe I get the chance to chat with them at a conference over beers. The other aspect that I need to keep in mind when I’m envious is that I don’t know how they got to where they are. I have no idea of the fires that burn in them, the sacrifices they’ve made, the late nights and hard choices they’ve endured.

So in short, my envy is unrealistic because I don’t know what their life is like nor do I know what their path has been to get to where they are now.

So, if the envy is unrealistic, should I ignore it? I don’t think so. What I try to do, not always successfully, is turn it into inspiration. After all, the reason I feel envy is because I want what they have. So why not see what they’ve achieved as a goal and go get it.

They may have learned and worked toward what they’ve achieved in public, in which case I have a blueprint to follow. Or, they may not have done so. In that case, the mere fact they’ve achieved something indicates to me that it exists and can be done. Bannister ran a sub four minute mile in 1954. It became possible, and others followed:

By the end of 1978, over 200 runners had broken the once impossible barrier of the four-minute mile.

https://www.mayooshin.com/four-minute-mile/

So rather than feeling unrealistic, unhelpful envy, I look to the people on the internet who have shared their accomplishments and feel inspired. Wow, someone came out of school and self published a book! Someone else went from three hundred followers to thirty thousand. And someone else built a side hustle into a business. All these things can be done with effort.

I can be inspired all day long, and it is far more beneficial to my mental well being than envy. However, both emotions don’t matter much in terms of getting things done.

This leads to the last point. When I see someone with large achievements, I can choose to follow in their footsteps. Take their accomplishments as my goals. Or I can choose to think about what it might have taken them to get to where they are, what sacrifices they’ve made. That leads to the most important question when I start to feel envy.

Am I willing to put in the time and the effort to try to get what they’ve got?

Sincerely,

Dan

Outcomes over output

This is a guest blog post from Mark Sawers. Enjoy.

Dear new developer,

As a software engineer, it’s easy to take our eye off the ball. The ball we really want to pay attention to isn’t the stuff we focused on in college. The ball is improving business/organizational outcomes. There isn’t a course of study or advanced degree on this, because it’s bespoke and custom to every organization.

You are on a team in your organization’s grand game to help the underserved, make money for shareholders, find some cure, save the planet or whatever its mission. A software-intensive system improves information access, automates task, entertains, etc. You pair with your business discipline in conceiving, building, testing and operating systems that advance the game.

Your real value to your organization is in improving outcomes. Not directly in how well you wield language X, tool Y, process Z. Not in how many features you add in a sprint, how many bugs you fix in one day, how much code you reviewed yesterday, how many answers you posted in slack, how many documents you wrote last month, and so on. Those are just means to an end.

Yes we need to constantly develop and hone technical skills (analysis, modeling, diagramming, programming, unit testing and others) and tool knowledge (languages, frameworks, utilities, operating systems, and more), but don’t mistake this for the end-game. Yes we should measure productivity; we do care about efficiency and throughput. But more product features, the latest tech, continuous deployment, two-factor authentication, and so on are not the goal. More is usually less, in my experience as a user. Isn’t that yours as well?

The goal is not output; the goal is outcome. The outcome is more revenue, more profit, more users, more product availability, happier users … right?

So, wait, isn’t that someone else’s job? What do you know about forecasting and measuring profit, anticipating user needs? Isn’t that on the product owner? The product manager? Marketing? And isn’t uptime the operations team’s responsibility? And finding problems the QA team’s responsibility?

You are on a multi-disciplinary team. You have at least one vital role to play on this team. Engineering is your trained discipline, and likely you focused purely on development. The smaller the company/business unit, the more hats you will wear. Yes your main contribution is technical, but in service of the bottom line. But don’t stay in your lane! Different perspectives are essential to this game. Your product owner doesn’t have a patent on designing end user features. And she may not be thinking about measuring success. Help her define the metrics and build those collection and reporting tools into the product. After you deploy a new feature, assess its success; don’t immediately move on to the next feature.

OK, so do I eat my own dog food? I try. The tech side requires lots of cognitive space, and so outcomes are easily short-shafted. Also, I have found this holistic perspective difficult to practice in large organizations. There is lots of specialization. It fragments responsibility. Incentives are set along discipline silos. My suggestion is to play your organization’s games (don’t leave that bonus on the table!) but bring your enlightened perspective as best you can.

Good luck,
Mark

Mark Sawers has been practicing software engineering for almost 25 years, as a developer, architect and manager. You can find his blog at http://sawers.com/blog and his LinkedIn profile at https://linkedin.com/in/marksawers .