A letter to myself as a fresh software engineer

This is a guest post from Luca Florio, lightly edited. Enjoy.

Dear Self,

You just graduated and you are ready to start your career in the IT field. I cannot spoil anything, but I assure you it will be an interesting ride. I’m writing you this letter because I want to give you some advice that will help you be a better professional. Nothing you won’t learn by yourself in the next few years, but it is something that I wish someone had told me when I started my career. They are not ordered by any means and are all equally important.

Run a marathon, not a sprint.

The road to becoming a good software engineer is a long one. Don’t rush on stuff, and don’t give up just because you are not getting an easy and fast win. Take your time to learn and become good in the topics you are interested in. Remember that this is a marathon, not a sprint.

Be humble, not stupid.

It is good — sorry, it is fundamental — to be humble. There is always something to learn from others, even when you are an experienced professional. But this doesn’t mean that everyone is better than you. You have to respect yourself and your skills. When you don’t respect yourself you become stupid, not humble.

Compare with yourself, not others.

There is no point in comparing yourself with others. There will always be someone better than you in your job. And there will always be someone better than the one that is better than you. And there will… ok, you got the point. Just do your best. If you think someone is a better engineer than you are, learn from him/her. Keep doing your best, and eventually, you will be a reference for someone else.

Respect people, not titles.

During your career, you will work with exceptional professional. Most important, you will meet exceptional human beings. Respect people for who they are, not for the title they have. If “foo” is “Principal Senior Lead Engineering Chief Architect” doesn’t mean that he deserves more respect than “bar” that is a junior software developer.

Choose the challenge, not comfort.

The road will be full of crossroads. There may be multiple choices, but everything boils down to a choice between your comfort zone, or go outside your comfort zone. There may be a moment in your life — hopefully after decades of work — when you will feel the need to cool down a bit because you will be satisfied with what you achieved. Until that moment, try to go out of your comfort zone. It will make you a better professional and you will feel more satisfied with your career. Remember that the best things often happen outside the comfort zone.

Jump on the whiteboard, not on the keyboard.

When you have to design a new feature or a new system, don’t jump on the keyboard to start coding. The “muscle” you have to train and use as an engineer is your brain, not your fingers. Always think before acting. For this reason, jump on the whiteboard instead of the keyboard, and start thinking of what you should implement. Better if you have a sparring partner to challenge your thoughts. Oh, when I say “the whiteboard” I mean “every object that can help you think”, be it pen and paper, a notebook application, draw.io, etc.

Deliver value, not code.

Please don’t be affected by the NIH syndrome. There is no point in reinventing the wheel. Avoid wasting time in something that is already out there. If you can achieve your goal simply glueing together some tools, just do it. What you should deliver as a software engineer is value to your business, not lines of code.

Choose life, not work.

In the IT field, it is easy to focus too much on work. After all, for most of us, it is not just a job, it is passion. Remember that work is important, but life is more. Live a meaningful and rich life. Play sports, read books, find hobbies, travel and see the beautiful world we are living in. Hangout with friends, find a partner for your life and give to your partner all the love, attention, and support that you can. You’ll be surprised how much having a rich life will improve you as a professional.

That’s all I can tell you right now. I still have a lot to learn.

One last thing: enjoy the ride! 🚀

With love,

(a more experienced) You.

Previously published at florio.dev.

Luca Florio is a Software Engineer working remotely for Pleo, a Danish startup. He loves to study new things and share what he learns in his blog.

How to be a 10x engineer: Business value for technologists

This is a guest post from Donnie Berkholz, lightly edited. Enjoy!

Dear new developer,

Since joining an enterprise (the world’s largest business-travel company) a while ago to drive their DevOps transformation, my ongoing mental evolution regarding the value of technology has gone through an almost religious rebirth. I now think in a completely different way than I did 10 years ago about what technology is important and when you need it. If you want to become a 10x engineer, you need a different perspective than just working on things because they seem cool. It’s about working toward the right outcomes, whereas most of us focus on the inputs (what tech you use, how many hours you work).

It all comes down to business value. You need to contribute to one of the core factors of business value, or however incredible the technology is, it just doesn’t make a difference. If you don’t know what that really means, you’re not alone — most of the technologists I know have trouble articulating the business model of their employers.

I think about it as 4 primary factors:

  • Money. This comes in two flavors. First, you’re creating new efficiency, which increases the profit margin. This could either be through lowering the underlying fixed costs of running the business, or decreasing the cost of goods/services sold by saving a little money on every one. Second, you’re increasing sales, which grows overall revenue. In a cost center within a larger enterprise, or in saturated markets, the former is the most common mode of operation because it’s hard to capture new opportunities. In the latter, it’s about growth mode – investing to capture new value, and often assuming you can make it profitable later. This could be framed as “land and expand” or with the assumption that your company will increase the price and margin once it’s gained a sufficient market share to do so with lower risk. Do you understand your company’s business model? Where does the money come from, who are the customers, what are their needs, what is the sales process and cycle, and what are they buying?
  • Speed. Again, there’s a couple of versions of this that overlap. The overall goals are either initial time to market or speed of iteration. Time to market can come at the expense of significant technical debt, while long-term accelerated iteration cycles are about product-market fit. If you know of the Lean Startup approach promoted by Eric Ries, this should sound familiar. From a long-term perspective, iteration cycles require a balanced approach of customer perspective and technical debt. Otherwise, your company can’t deliver value to customers quickly due to accruing interest on its tech debt. In practice, this can drive an approach that involves gradual refactors with the assumption that long-term rewrites (or e.g. strangler pattern) will be required. It’s the classic “design for 10x but rewrite before 100x,” to paraphrase Google’s Jeff Dean.
  • Risk. As before, this essentially boils down to executing on new opportunity or loss to existing opportunity. Dan McKinley has a fantastic post on why you should choose boring technology, because the important risks are in the business model vs the tech. You should only make a small number of bets on new technology when it will really make a difference in your ability to deliver on business value. For existing opportunity, it’s more about risk avoidance. Typical approaches tend to end up in some mainframe application that one nearly retirement-age developer knows but is afraid to touch. However, a more sustainable model is to implement heavy automation if it truly is a business-critical application that justifies the investment. Relatedly, risk avoidance is where security shines. One of my favorite perspectives is Google’s BeyondCorp model, which assumes your perimeter is compromised and acts accordingly.
  • Strategy. Often not immediately visible in the above approaches, investing in strategic growth opportunities is consistently a great path to success in your business. Do you know your company’s strategy? They probably have posters up and meetings about it all the time. Could you say it out loud? Do you know how it maps to concrete actions? Although any individual opportunity may fail, your contribution to executing on the technology behind that opportunity will not go unnoticed. Similarly, if you’re involved in divesting from areas your employer wants to leave as part of its strategy, you have a real but often smaller opportunity to leave your mark upon the work.

Although many other factors have an impact upon business value, those are 4 of the most important ones that can make you consistently successful as a technologist. The key is to understand which ones play into your work, so you can act accordingly in your day-to-day efforts and as part of your career strategy. Are you building software for a cost center, a growth incubator, a risk center, or at a company that cares to invest in speed? Taking full advantage of this approach could make you the 10x engineer you’ve always wanted to be. Best of luck in your journey, and may you spend time where it matters!

Sincerely,

Donnie

Donnie Berkholz has been driving the DevOps transformation at CWT (formerly Carlson Wagonlit Travel) since early 2017. Prior to that, he led a global team at 451 Research providing research and consulting around leading-edge trends in software development and DevOps. His background includes roles at RedMonk — where he focused on DevOps and open source — and well over a decade at Gentoo Linux, where he worked his way up from a developer to lead a group of more than 250. One of his passions is the social side of technology, and he’s led initiatives to turn around unhealthy teams as well as measure and act on open-source community metrics.

He got into tech almost by accident, because his role as a biophysicist got increasingly computational and he decided he wanted to focus on the technology. Prior to tech and science, he did a stint as a journalist. Donnie now combines that diverse skillset in communications, data-driven thinking and technology to drive companies toward differentiation with leading-edge technology.

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 .