Writing great software isn’t all about the software you write

This is a guest post from Adam Leventhal. Enjoy.

Dear new developer,

I love software engineering. Even as excited as I was to start my first job, I didn’t imagine the deep and enduring joy it would bring. In my career, I’ve oscillated closer and farther from writing code, and while management and entrepreneurship are wonderful, there’s nothing like the pure joy of building software.

Building great products takes a team. Code is a critical piece, but that doesn’t mean you need to stick to your narrow lane. Yes, developers write code, product managers write specs, doc writers write docs, marketing writes slides, sales sells, support supports, etc. Focus is important, but it’s a myth that doing your job well requires focus at the expense of understanding the holistic view of how products are built. Understanding the full product lifecycle–from conception, to purchase, install, and support–will make you better at your job and lead to better products.

One of the first things I worked on professionally was a product called DTrace. It’s a tracing tool to help understand how systems operate. It’s used to find bugs, chase down performance problems, or explore how a code base operates. I was drawn to the project early on because of the extremely precise and creative engineering required to safely instrument running programs and kernels. It was all very cool, very satisfying. An extremely formative moment in my career came when I was demonstrating an early DTrace prototype to a customer. We used this new lens into their software to understand behaviors that had always been mysterious to them. Their ideas came one on top of the next as we exposed all kinds of crazy behaviors and pathologies on the fly. I had seen the power and utility of what I had built in my own use, and my team’s use. Seeing a customer–and engineers quite different from me–get so fired up was eye opening. I still wanted to build cool stuff and write hard code, but understanding the problems it solved and the people who used it informed my work from then on.

There were three engineers working on DTrace. We were our own product management. We built features we needed to solve urgent problems for ourselves and customers. We were our own marketing, giving talks and writing blog posts. We were our own doc writers, churning out a hefty users guide. Those activities weren’t downstream of development, they were an integral part of it. When building a feature, we talked about how to explain it to sales people, to users, to support engineers. Sometimes that meant changing what we had planned to build: if you can’t write the documentation for a feature you’re probably building the wrong feature.

Almost a decade later I joined a new team that could not have been more different. The development team was comfortable in their ignorance of the broader product. They didn’t just stick to the code, they were narrowly focused on just their own subsection of the code. In the Solaris Kernel team where we built DTrace, we would follow bugs up and down the stack, through multiple, enormous code bases, to determine the root cause of problems. Here, developers were content to chase a problem to the edge of the module they owned, and then reassign the bug to the developer who owned the next module. The team barely had a shared understanding of what they were building, much less of that true north of customer need. That gap was evident in the end product: modules were poorly integrated and features fell short of solving customer problems.

Whatever you’re working on, understand not just what’s needed, but why. Listen in on a sales call, talk to a customer, or do a ride-along with a support engineer working on an escalation. Some companies have great programs to involve engineers in the broader product lifecycle. If yours doesn’t it’s probably (hopefully!) because no one has asked. Empathy is an engineer’s greatest asset: empathy for the customer to understand their problems and priorities; empathy for the doc writer trying to explain a complex feature; empathy for the next engineer to pick up your code and make sense of it. Empathy starts from a curiosity to understand what and why.

Find true north for the products you work on. It will make your work better and bring you more satisfaction.

Adam H. Leventhal is an engineer at Oxide Computer Company building a new, modern computer. Previously he was a software engineer at Sun Microsystems, CTO at Delphix, and co-founder, CEO at Transposit. He’s sheltering in place in San Francisco with his wife, teen, toddler, and two dogs. Find more of his writing here, here and here.

Don’t sign anything you can’t understand

Dear new developer,

I want to preface this with the fact that I am not a lawyer, so please don’t take this as legal advice. This is my experience with employment contracts and other legal adventures as a software developer.

When you are starting a new job, you’ll be confronted with a big basket of paperwork to sign. Actually, nowadays it’ll probably be a pile of PDFs. When you leave a job, you may sign a termination agreement, which again will be a lot of legal documents.

Read all of them. If you don’t understand something, ask what it means.

These legal agreements can profoundly affect your career. (Here’s an example of a noncompete causing a fair bit of legal pain.) It also doesn’t really matter what someone like your boss says when you are hired or leave–it’s the legal documents everyone signed that will control. (Often the employee handbook is incorporated by reference into your starting docs. Ask to see that as well.)

So read them and understand them. If someone won’t answer what a phrase means, seek info from someone else at the company, perhaps HR. You should, in certain circumstances such as a layoff, make sure you get the document reviewed by a lawyer who is looking out for your interests.

I have only sought advice from a few lawyers in my life, but all of them I found through referral. I’d recommend finding your lawyer that way as well. Ask family members, other professional contacts, or even people you’ve interacted with online in your area for a recommendation. A good lawyer should:

  • cost a lot of money–my most recent lawyer charged $475/hour
  • be willing to listen
  • focus on understanding what you want from them (for example, “is this employment contract normal”)
  • stick to your budget; make sure you communicate that
  • be local–different laws apply in different countries, states and cities
  • have expertise in the area and be willing to refer you if they don’t

You’ll pay for the certainty of a lawyer’s review, which is why you should check out the documents and only ask about sections you don’t understand, rather than sending them the entire document.

Now, for higher risk/return situations, it may be worthwhile to have every document reviewed. When I joined a startup as a co-founder, I had the entire agreement reviewed. But I don’t do that for my normal employment agreements or any contracts I sign as a consultant.

There are three main benefits of reviewing these agreements. (I’ll focus on employment agreements as those are by far what I have the most experience with, but realize you should read and understand any legal document you sign.) The first is that often there is scope for you to protect previous projects, ideas or side businesses. This can be as simple as listing the project in broad terms. Should you have any desire to commercialize a project in the future, doing this ensures it is not entangled with your employer’s properties.

Another benefit is that you’ll know your rights. Even if the agreement is punitive, wouldn’t you rather know, rather that discover it after you’d violated the contract? Here are things I look for in an employment contract:

  • Who owns what I create while on the job? As an employee, it will almost always be the employer. If you are contracting, it can vary and I know people who’ve started businesses because they had the insight to ask for non-exclusive rights to the code they were creating.
  • Who owns what I create while not on the job? In most cases, you should own anything you build on your own time, but be wary if the company works in a similar area, and if you use company resources to do the building. Get clear on this. (Some states, such as California, have explicit laws explaining the boundaries.)
  • What limits are placed on me after I leave? Do I have a non-compete, and if so for how long? How broad is the non-compete–what areas of employment are now off limits? What about confidentiality agreements? Is there anything else I need to do? One company employment agreement dictated I let them know where I was working for three years in the future.
  • What am I getting paid? Any salary or bonuses that were mentioned verbally should be included in written form, either in the offer letter or employment agreements.

It’s worth noting again that the verbal promises of anyone at the company are typically worth far less than the written agreement. I’ve had some employers honor verbal agreements (and those are good employers to stick with!), but typically when the rubber meets the road, what is written down is what will be enforced. So if someone says “ah, don’t worry about that clause” then simply ask if you can strike it from the document. And if someone promises you something, ask for it in writing. No need to be arrogant, but realize that if anyone in a business setting won’t put a statement in writing, getting what was promised will probably be difficult.

The final benefit of reading what you’re signing is that now that you have protected some of your previous inventions (if any) and know what you are agreeing to, you can negotiate.

The amount of leverage you have to change any of these agreements depends on how big the company is and how much you are desired. If you’re a new developer and the company is large, they probably won’t budge. If you’re a senior engineer that the hiring manager really wants, clauses can be negotiable. It doesn’t hurt to ask.

I understand that you may not feel you have a lot of power. You may have gone through a grueling interview process and may not have many other options if you don’t take this job. In that case, you don’t have a lot of negotiating power, but at the least you can know what you’re agreeing to. The earlier you can see these agreements, the better. The best is if you can see them before you turn down any other job offers.

At the end of the day, these agreements can have a large future impact on your career. They can limit who you can work for, what you can do, and who owns what you have made. Understand what you are agreeing to.

Sincerely,

Dan

Take time for decisions

Dear new developer,

For large long term life decisions, you should realize a few things.

First, that few decisions are 100% irreversible.

Second, that the choices you have in the future are based on the choices you make (this is called path dependence).

Finally, that you should take time for important decisions. In fact, you should consult others, spend some time dwelling in your own head, and sleep on it.

Consulting others

I like to check with other people who have been in similar situations when confronting a big decision (like switching a job or starting a consulting company). This of course means that I’ve kept in touch with them over the years (via LinkedIn or by other means). This can be as simple as a coffee or beer or phone call. Even an email where you document the choices as you see them can be clarifying.

Note, you don’t have to do what they suggest. What you want is someone who:

  • is close enough to you to have context, so their opinion matters
  • will be honest in sharing their opinion
  • is going to make you see the decision in different ways
  • has experience with similar situations

Spend time thinking about it

Go for a walk. Write some things down (I’m a big fan of plus/minus lists.) Don’t think about the decision for a while. All of these will help you get out of your head.

I have found that it’s easy for me to get wrapped up in a decision and overestimate its importance. The work you do day to day in a company and the people you meet matter a whole lot. But there are many many excellent people everywhere.

But, you should definitely not feel rushed into any decision. If a person offering you an opportunity (whether that be a project, job or other choice) is rushing you into it, that’s a bad sign. It’s an indication that the choice can’t stand on its own.

Sleep on it

Finally, sleep on it. There’s an interesting discussion here, including tips to have a notebook by your bed, but the long and short of it is that if a problem is worth consulting others and dwelling on, often taking an additional eight hours won’t make or break the situation. And a night’s sleep can allow you clarity. Sometimes things that seem true the night before (“I am afraid of taking this job”) appear in a different light after (“What I’m really afraid of is change”).

Sincerely,

Dan

What’s your best advice for a new developer?

Dear new developer,

Dev.to is a relatively new community of developers. A few years ago, someone on that community asked for advice for junior developers, and I found the answers fascinating. Here are a few of my favorites.

People should respect you. It’s your right to push back against disrespectful interactions. If it’s waved away with “oh, [person] is just like that,” know that a) that is bullshit and b) both the person being disrespectful AND the one dismissing it are wrong. – Sarah Mei

Respectful communication and interaction is the foundation of trust, which is the foundation of team building, which is the foundation of software delivery.

Not getting your pull request through code review first time is okay. Everybody has their own approaches to problems, and a comment on your code review saying “X could be improved by Y because Z” doesn’t necessarily mean you’re not a good enough developer for only thinking of X, rather than Y. It’s usually more a case of your haven’t encountered a scenario that leads you to see the reasoning Z that causes you to use Y over X yet. – Aidan Walters-Williams

We all have something to learn. And our code is not ourselves, so when someone tries to improve our code, they aren’t attacking us.

Reporting a problem you’ve discovered is good, thorough analyses are better, proposing a solution is best. It doesn’t have to be right, it just has to start the discussion. – Dian Fey

It’s always good to go a step beyond reporting a problem because a) additional investigation may reveal it isn’t actually a problem and b) if it is a problem, the more you provide up front, the easier it will be for anyone trying to solve the problem (including future you) to replicate the context and hence investigate the problem with less effort.

There are a lot of great gems in the post.

Sincerely,

Dan

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.