Create Value for People

This is a guest post from Minh Pham. Enjoy.

Dear new developer,

I want to start off by saying Congrats and Good job. If you’re reading this, it’s likely you know how to code – and even if you’re still working on getting that first job, that means you have one of the most desirable skill sets in the world today. I congratulate you because getting here took work. You weren’t born with this knowledge, and even if you felt like it came naturally, it was still a journey of discovery, learning, and practice that got you where you are today.

As you look towards your first job – I want to offer you a single piece of advice that may act as your career’s guiding north star:

Create Value for People.

When you have the power to create anything, you begin to realize the importance isn’t on the code you’re writing but rather why you’re writing it in the first place. What value are you creating through your skill? This is why companies hire people like yourself. They are seeking out individuals who can ultimately deliver value to their customers, particularly through software. As you mature, you will realize that much of engineering has little to do with how fancy your solution is, and instead has everything to do with what problem it solves for the user. Once you accept this, you’ll begin to see that discussions of tech choice and code structure rarely matters outside the context of what business value it represents.

This is where your focus should stay.

Obsessions with patterns and algorithms don’t serve anyone’s mission by themselves. Ignore the constant pressure to assert yourself through syntactic cleverness and obscure trivia. These things don’t matter. These things don’t drive value for anyone. No matter how many “experienced” engineers tell you these are important, I promise you no company hires people simply for them to recite principles and algorithms.

While coding might be your latest skill set, it is by no means an engineer’s only skillset. Remember that at the end of the day, it doesn’t matter if your code is ugly, fancy, verbose or concise – the value you create matters. Strive to be an excellent communicator, a quality teammate, and an outstanding human. These attributes will guide your engineering efforts to ensure you bring value.

No matter where your career goes, if you focus on creating value for people, opportunities will never be in short supply. Desire for specific skills may rise and fall, but people will always look to those who can create value.

With that, I wish you the best of luck and may our journeys cross again,

Minh Pham

Minh Pham believes you should lead how you want to be led. This has been the guiding principle of his career since he started. As an Engineer, he always wished he had someone who would guide him – telling him what’s important, what he has to work on, and what he should ignore. Having gone through all that and then some, Minh now looks to be the positive influence he wishes he had.

As a manager, Minh’s greatest passion was teaching people the skills to create and drive the careers they want to have. Now as a career coach, he works to show people they have the power to build the life they want.

Minh believes anyone can do it – and he promises it doesn’t involve linked lists or graph traversals.

When is it time to quit my 9-5?

This is a guest post from Pariss Athena. Enjoy.

Dear new developer,

Honestly, I don’t think there’s one absolute answer. I believe the answer depends on you and the risk you’re comfortable taking. However, I do think there are things you should take into account before jumping the gun. This is how I personally knew it was time to give my notice and take my business full time…

Everyone’s situation is going to be different. This is my story.

I announced that I was launching Black Tech Pipeline (BTP) in June of 2020. Around this time is when everyone was really riding the Black Lives Matter train, and claiming their allyship after George Floyd’s murder.

This was not why I decided to launch. Weeks prior to the pandemic and quarantine, I was constantly tweeting about launching BTP “in the next weeks.” Those next few weeks just happened to fall during a tragic time.

But these two things did contribute to the eagerness of announcing my launch:

  1. I knew my performance at work was dropping. I stopped attending happy hours, and engaging in conversation. It wasn’t because there was something wrong with the company I worked for, my focus just shifted.
    I was rightfully distracted by social media and the flooding of content surrounding the injustices happening in the Black community. Knowing the work I should be doing full time vs the work I was actually doing full time made me annoyed with myself. I wanted to just help create impact in my community. That’s it.
  2. I was pissed the hell off.

I want to preface this by saying that I know I have the privilege of already having a platform and a following. I know that contributed to the traction my launch announcement received.

I had been writing newsletters surrounding Black Lives Matter a few weeks before announcing my launch, and those newsletters gained lots of traction on social media, which gained me more subscribers. I decided to announce the launch of BTP in my newsletter, and the response to the announcement was sign #1 that I was going to be on my way out of my job.

My calendar was flooded with calls. I had 15 minute breaks in between calls from morning to evening. I was talking to employer after employer wanting to take advantage of BTP’s services. Aside from calls, I received emails non-stop. Not just from employers, but from opportunity extenders of all sorts. It was tiring but good problems to have, especially before even launching.

On top of my performance dropping at work from being distracted by the political climate, I was now also distracted by BTP’s calendar being completely booked. Having so many calls booked seems promising, but until I had client agreements signed and invoices paid, I wasn’t going to leave my job, especially during a pandemic.

Plenty of employers expressed interest. They loved the origin story of #BlackTechTwitter and how it led to me building Black Tech Pipeline. There were lots of promising words, but you can’t go off of words of interest to determine your safety net.

The way I determined my safety net was by looking at my finances with my mentor, Leon Noel. I kept in mind what I was making annually at my 9-5. I already knew what I was charging for my services so I also used that to think about worst and best case scenario. He told me to ask myself:

  1. At the very least, how much do you need to make to pay your bills on time?
  2. Are you willing to give up your typical lifestyle?

I looked at my pricing model and mapped out how many clients I’d have to have per month to get by. And not just how many clients, but:

  1. Which services would those clients have to pay for in order for me to get by?
  2. And when those clients pay me, how much money do I have left over after putting 30-35% into savings for tax time and personal savings?
  3. And if I don’t want to live a life of just getting by, how much money do I need to make, with tax deductions in mind, to live the life that I want to live?
  4. How much money would I like to make annually? What will it take to get there? Can I project that?
  5. Is it possible that I can stay at my 9-5 and balance my business at the same time?
  6. Could I potentially hire someone to help me out so that I can do both?

Those numbers and questions are extremely important and it’s what you should think about before making the decision to bounce from your 9-5.

Sign #2: Personally, time was not on my side. It came to a point where something had to give. It wasn’t fair to continue working my 9-5 when I wasn’t giving it my all because I was busy prioritizing my own business. I also wasn’t willing to give up potential clients, miss calls, and wait to reply to business emails for the sake of my 9-5.

Sign #3: Potential clients turned into paying clients. Agreements were getting signed, and invoices were being paid. That sounds dope, but that’s not enough to say you’re secure. The question is,

  1. With the money you’ve been paid + your savings (if any), would you be able to quit your job and be able to pay your bills for the next 6 months, even if you got no other paying clients?
  2. How many signed/not yet paid clients do you currently have?
  3. What’s your projected paying client rate for the next month?
  4. What are you going to do if you don’t have any new business coming in?

These are the risk questions, and you have to be very real with yourself when you answer them. The last thing you want is give yourself optimistic answers and then be left with late payments, debt, and serious financial hardship.

My personal answers: I’d be fine. I determined this by the tangible money I had been paid. I didn’t count the client agreements signed because anyone can back out of an agreement before the work begins, something could delay the process on their end, etc. I made enough to feel confident in giving my job my notice, and to continue living the life I want to be able to live. I only considered signed agreements when I thought about future business expectations: “I have {x} many clients potentially secured for {x} services, which will keep me financially stable for {x months}. I also have {x} many potential client calls lined up for the next {x weeks/months}.”

I also double checked with my mentor, and when he approved, I felt even more confident in leaving.

It was bittersweet, but I gave my notice. It was time. ✨Shout out to G2i for being the best employer I’ve worked for since entering the tech industry. Amazing culture, dope people, and doing the work of solving the broken vetting process.

Now, I don’t know what’s going to happen with Black Tech Pipeline. Maybe things are only going well right now and we’ll struggle later down the line. I don’t know, I hope not. I will do everything in my power to make this company successful, but there’s only so much that I have control over. That’s the risk. That’s entrepreneurship for ya.

If I’m being totally honest, a job will always be there. Companies will always be hiring. I know- I’m a recruiter.

— Pariss

This post was originally published at Black Tech Pipeline.

Pariss Athena is the creator of the movement, hashtag, and community #BlackTechTwitter, and Founder of Black Tech Pipeline.

The Code Will Never Judge You

This is a guest post from Lorna Mitchell. Enjoy.

Dear new developer,

Recently, I decided my seven-year-old niece was old enough for her first programmable device. She has done a little bit of Scratch with me, so I bought her a BBC micro:bit (a very simple programmable device, with a web editor and USB connection, some buttons and some LEDs) and showed her how to get started. Then I said to my sister (whose child this is) “the tears are all part of the software development process, so try not to worry when it happens!”. However many years down the path I am myself, coding is still a rollercoaster and there are some downs as well as some ups.

One thing that makes software development more difficult is wondering if you are really cut out for this. It’s so easy to feel like you are doing software “wrong” in some way. Spoiler: there really isn’t a right way, it’s part art as well as part science. Keep the user in mind and apply the technology the best way you know how; you’ll go far.

Some days it doesn’t feel like it’s going well and you may wonder if you will ever be really good at your chosen profession. On other days, or perhaps overlapping days, other people will think you’re not cut out for it either. Maybe you think your skill set isn’t a good fit (it is), or that you don’t really look like a software developer (you do). It is very difficult to help other humans who have already decided that they don’t quite believe in you. From extensive field testing, I have found that almost none of them ever change their mind.

In fact, this is much less important than it seems. If you don’t understand the pop culture that inspired the bot/server names, you didn’t play the same computer games or watch the same films (I’ve still never seen Star Wars), that doesn’t impact on what you can be. For minorities of all stripes, not sharing the supposedly shared culture can really make you doubt yourself. That’s a human reaction, don’t feel bad for feeling your feelings. If you want to be a person who does play those games and watch those films, then go for it.

But if you are just there to be the best software developer you can be, then let the other things go past you, and focus on the things you really do want to learn from, and share with, the crowd. I think most of what I know about text editors, information security, and leadership I learned from colleagues or conference encounters. It took me far too long to realise that software developers do look and sound like I do, and my own interests and hobbies are no less valid than anyone else’s (I also know more very technical humans with yarncraft hobbies now).

The code will never judge you. You show up, try things out, keep learning, keep iterating. That’s how software is made. It isn’t made of what other people thought you could do, it’s only made of what you did do, and for that you need to show up, and do.

— Lorna

Lorna is based in Yorkshire, UK; she is a Developer Advocate at Vonage as well as a published author and experienced conference speaker. Lorna is passionate about open source technologies and sharing knowledge, code and experiences with developers everywhere. In her spare time, Lorna blogs at https://lornajane.net.

You’re gonna be OK

This is a guest post from Jerome Hardaway. Enjoy.

Dear new developer,

So, you’re in the office, learning a million things a minute that you were never exposed to. Everyone around you seems super competent and you don’t want to take time away from them, but you have no idea what you’re doing. You feel like you should probably be a janitor instead of working on a million dollar web app. I’m here to tell you, you’re wrong.

Every person who seems competent has felt like you or still feels like you do, they are just better at hiding it. I know people who have been doing this work for years and feel silly at least once a week. Hitting your head against the tech wall is a rite of passage here and normal and whether they tell you or not, we have all been there. We have all either accidentally taken down prod, nuked the repo, felt lost, accidentally ran up the AWS bill, and just straight up sucked at this job. So long as you focus on having more good days than bad, you will be fine. More than that, you’ll do great, so relax cause we are all rooting for you.

— Jerome

Jerome Hardaway is a Developer Advocate at Quicken Loans and Executive Director at Vets Who Code, Where they help veterans get jobs in software by teaching them how to program for free.

You’re probably going to want to quit

This is a guest post from Mia de Búrca. Enjoy.

Dear new developer,

You’re probably going to want to quit.

The very qualities that make writing software appealing can also make it frustrating beyond belief. You’re headed down this path because you like to be challenged, to learn and grow. However, facing new harder problems day in, day out can take its toll on your morale. And keeping up to date, familiarising yourself with the breadth and depth of topics in this domain – it can be overwhelming. But if you’re reading this it’s likely you’ve already felt the deep satisfaction of writing code to be proud of, so I hope that by sharing my experiences, from early in my career and from a few weeks ago, you will be motivated to push through and keep enjoying the journey.

The Import

One of the first times I nearly quit was a few weeks into my first role as a dev. I was fortunate enough to land a great job at a small startup, and I was pretty awe struck by the talented and motivated people on my team. So after a while of pairing, I picked up a piece of work to try on my own. After doing some copy-pasta from other files and then tweaking I was chuffed and attempted to view the web page that would now be perfect, right?

Much to my dismay I was met with a blank page and an obscure error message. Baffled, bit by bit I undid all my changes, at each step feeling less worthy of the job, until nothing was left except one measly import statement. I could feel myself go red in the face as I still couldn’t understand what was going on. I should be able to do this, but I’m not good enough. Eventually, I turned to my mentor to admit defeat, and my panic dissolved when he said “oh yeah, this one is definitely confusing” then casually pointed out a simple syntax error. I realised that unlike him, I was not yet equipped with the necessary debugging skills, I was not yet familiar enough with the language I was working in to decode the error message. It takes time.

The Library

It has been four years since the import statement that stumped me, but just a few weeks ago, when I volunteered to update a library which was many versions behind, this seemingly trivial task wound up with me ready to quit yet again. Between a broken development environment, failing tests (was it the tests… or the code?), and still this library integration that refused to obey, I was at a loss. I should be able to do this, I should be good enough by now surely? These thoughts drove me to stubbornly dig my heels in and devote hours to diving into the library source code, reading in circles, dipping in and out of StackOverflow, getting more and more frustrated. Much time wasted I was no better off, so I went and made myself a cup of tea and called up a colleague and good friend to lament my problem. Typically, within seconds of this accidental rubber ducking session the solution to my worries became apparent.

The Lessons

And I could probably list countless other occasions. There may be many different things that leave you feeling like quitting, for me it often boils down to not feeling good enough to tackle a problem. But when you come up against a roadblock, you shouldn’t see it as a reflection on your own ability. If like me you find yourself paralysed by feelings of inadequacy, recognise that the foundation of all programming is problem solving – if there were no annoying problems, you wouldn’t have a job – and as you progress through your career you will gain more tools to solve them. Step back and remember, when it comes to tech, there is a reason to be found – sometimes it takes time, distance, or some help to see it.

These are lessons you should try to internalise, or like me you’ll relearn them throughout your career. You can’t change the fact that deeply frustrating problems are coming your way. You can only change your perspective. Put your energy into solving the problem and don’t assume that you’re not good enough. “Good enough” is an arbitrary concept, an ever moving goalpost. Give up on the notion of “good enough” and instead give yourself some time.

Sincerely,

Mia

Mia de Búrca is a Senior Software Engineer working full stack at 99designs, a company connecting creatives around the world. Originally from Ireland, Mia started out as a translator and computational linguist before landing in Melbourne, Australia and setting her eyes on a career in web development. Mia enjoys solving problems with a focus on bringing real value to users and seeks opportunities to create a supportive and empowering workplace. When not hiding from apocalyptic pandemics, Mia is also a circus performer and teacher.

Choose inspiration over imitation

This is a guest post from James Turnbull. Enjoy.

Dear new developer,

Steve Jobs made the phrase “Good artists copy, great artists steal” famous in the tech industry. However, there’s considerable debate about the origin of the expression. Ironically, he was possibly cribbing from Picasso, who might have been cribbing from Igor Stravinsky, William Faulkner, or perhaps T.S. Eliot. Of all the many variants, I prefer Faulkner’s “Immature artists copy, great artists steal.”

What does this phrase have to do with writing code? More than you’d imagine. As engineers, we’re often stuck on something, banging our heads against a wall over a block of code, or a problem we can’t solve. Some people go for a walk to overcome these blocks, and others take a shower or switch contexts. But many of us go searching the Internet for answers. We try Google, Stack Overflow, or Github for error messages, snippets of code, or implementations that might overcome our problem. When we find something that helps we take this code, often morph it a little, and then use it in our codebase:

Commit message

Or in a code comment:

# From https://stackoverflow.com/questions/62048888/how-to-select-a-floating-point-or-integer-using-a-regular-expression-from-text
text.lines.find { |l| l[' Running Total '] }[/[\d.]+/]
. . .

But there is a lot of disdain, even hate, for this approach from other engineers. This hate is often combined with gatekeeper overtones or remarks about how this wasn’t how things were done when they were learning. I’ve heard it described as “copy-pasta coding” or “cargo coding,” or sometimes even described as outright plagiarism. So is it plagiarism?

To me, there’s a clear distinction between imitation and inspiration. When you go looking for that code, you’re looking for inspiration to solve the problem you have. It is rare to find the exact code you need that you can without modification, nor do you often find code can be used by simply copying it in place. By the very nature of trying to understand how someone else solved the problem, you’re learning, inspired by their creation. Later, as someone finds your code when they seek to solve the same or a similar problem, they can see your implementation and the original, and potentially receive further inspiration and insight.

There are best practices, though, that you should abide by when you use this approach. Firstly, credit the source of your inspiration, acknowledge the work of the original author, and help the next person who is following the same path to a solution. Indeed, if you feel uncomfortable about acknowledging the source of the code that inspired you, perhaps that’s a signal that you’re not doing right by the original creator?

Secondly, use the code as a learning tool; experiment and apply your knowledge and perspective to it. I recently found a Ruby method to work with a nested hash. I liked the solution but realized there was a way to make it more functional and easier to understand. So I took the code, modified it, and made it my own. In has been my experience that the best code results from code shared, whether developed with others or even code reviewed to get other’s perspectives. This process is how we learn to be better coders by learning the lessons of those who came before us and building upon them.

So ignore those folks who hate on this approach. I am sure they protest too much because I can guarantee they have done this in the past, and their disdain draws from the rose-colored glasses that inhibit memories of how they learned. Great artists don’t spawn from nothing, and “Great artists steal” is about finding inspiration; finding the key or the “eureka” moment someone else’s implementation sparks and using it as a starting point to creatively solve your problems.

– James

P.S. This post draws some ideas from Adam Kurtz’s excellent Things Are What You Make of Them and from numerous articles and interviews from the team at The Creative Independent. I strongly recommend both if you’re interested in understanding artistic creation and how great artists create.

James Turnbull is an engineering leader, author, and open source developer. James was the VP of Engineering at Glitch, a CTO-in-residence at Microsoft, CTO/Founder at Empatico, and CTO at Kickstarter. He was previously in leadership roles at Docker, Venmo, and Puppet. James was chair of O’Reilly’s Velocity conference, speaks regularly at conferences, advises a number of startups, and teaches engineering and technology skills. You can find him on Twitter.

How I Got a Job Two Weeks After My Coding Bootcamp

This is a guest post from Randall Kenna. Enjoy.

Dear new developer,

Two weeks after I graduated my coding bootcamp, I had an offer. Two weeks after that, I started my first engineering job at a small startup.

Here are some of the strategies I used.

Treat your job search like it’s your job.

I was exhausted after I graduated from my bootcamp. But I had spent more than$15,000 on tuition and living in San Francisco so I knew I needed to get a job quickly to prove the financial investment was worth it. It was so tempting to just spend those two weeks napping on my couch and recovering from the most grueling process of my life but using the momentum I had from graduating the bootcamp was critical. I had read about a lot of students that had let their skills get rusty and it had taken 6–12 months for them to find a job.

From the hours of 9AM to 6PM, I was job hunting. I was obsessively updating my resume, finding new jobs, reaching out to connections, finding meetups to attend, and honing my skills. After 6PM, I wouldn’t respond to recruiter emails or do any prep work for interviews. I used that time to recuperate and prepare for the next day.

Optimizing my LinkedIn

The company that I ultimately ended up taking an offer at actually found me through my LinkedIn. For all the applications that I sent and meetups that I attended, they ended up finding me and asking me to come in for an interview.

I filled out my LinkedIn with my prior jobs to show that even though I didn’t have a ton of engineering experience, I had a past career where I had been paid to code a little in some of my past jobs. I added every course I had taken and every certification that I had gotten during the bootcamp to show that I was very interested in engineering and it wasn’t just a job to me.

Quickly moving on from companies that weren’t a fit

A few companies had interview processes that were equivalent to Google. They wanted a coding bootcamp graduate to be able to solve complex algorithms that even a software engineer with a CS degree and years of experience would have struggled to complete.

I would have spent so much time preparing for just one interview at one company when instead I could use that time to go through the interview process at several companies. I told the company that the process was far too intense for a junior engineer and moved on.

You don’t have to use this strategy however if you’re willing to put in a lot of time learning algorithms and focusing on building some CS foundations. Some people in my cohort focused on their algorithm skills and it took a little longer to find a job, but they started out with a better title and higher pay.

Build a coding portfolio

Thankfully, my coding bootcamp had helped me create a large portfolio with several applications. I was able to take this to prospective companies and discuss what I had learned during the project. In my final project, I had focused mostly on frontend so I took that work to companies and detailed exactly what I had worked on.

If you don’t have a portfolio yet, just get started on something small and push it up to GitHub. Each time you create a new project, challenge yourself to make it a little more complex than the last project.

Proving I was eager (and desperate) to learn

Two companies told me I could build a project in the framework that I was most comfortable in. But I knew that if I spent a little time learning the framework that they used, I would improve my odds of standing out.

Over the weekend, I taught myself the framework one company used and built a small (and very barely working) app that used it. I was able to discuss the principles of the framework and even though my app broke during the demo, I got the job.

This was a risky strategy because I ended up not spending any time learning the other framework for the other company but it worked out in the end when I received an offer from the company.

Focusing on my strengths and not my weaknesses

I knew that I wasn’t going to do super well at companies that focused on algorithms and prioritized having a CS background, so I intentionally found companies that wanted to focus on mentorship and had real world interviews.

In the interviews, I discussed how I had prior career experience that would benefit them if they hired me and I had been coding at those jobs as much as I could.

It definitely wasn’t easy but anyone can get a job in coding if you treat your job search as if it’s your job and keep improving your skills.

Sincerely,

Randall

This post was originally published at RandallKanna.com.

Randall Kanna is a Senior Software Engineer at BaseHQ, speaker and O’Reilly author. She’s formerly worked at companies such as Eventbrite, and Pandora.

Show up

This is a guest post from Elise Shaffer. Enjoy.

Dear New Developers,

As I sit down to write this letter, I’m struck by the thought that I don’t know you. You could be like me, a person who’s loved computers since she was nine years old and has taken every opportunity to learn more about them. You could also be one of the many people who’ve recently graduated a coding bootcamp after spending years in another career. You might have an experience somewhere in between or vastly outside the two.

So, the challenge put to me is to give advice about starting out in development that would be applicable to you given the wide range experiences that might have brought you here. Thinking about that led me to a revelation that the best advice I could give is to show up.

Software is about human relationships. I know this is a point that’s appeared on this blog before. I won’t rehash all the reasons that’s true, but I will use it as a starting point to say that it’s important to have people with diverse experience designing software. It’s important that no matter where you are coming from that you show up. Bring your experiences, struggles, values, and tastes to your work as a developer.

You’re starting out and will probably feel that you need to catch up to your peers. Certainly, there is always more to learn in software development. But you also have so much to teach those around you. Maybe you have an aunt who needs assistive technologies to use the web. Maybe a computing error caused trouble in your previous career. It’s easy to get lost in everything you don’t know. But, it’s just as important to draw on your previous experiences. For example, maybe you used to work in manufacturing safety systems. Safety is incredibly important in manufacturing and it’s also important in software. Or, you might have taken foreign language and culture electives in college that help you understand how design decisions will be received internationally. How can those experiences help you work on projects with your team?

Don’t be afraid to ask stupid questions. It might seem like a stupid question to you, but it’s more likely that what you’re asking is something the rest of your team takes for granted.

Software should support people. In order to do that it has to understand people and the only way to ensure that, is for those designing it to draw upon the biggest well of experiences possible.

There is always more to learn about programming. But, you already know so much that you don’t even realize. Bring that knowledge and experience to your work as a developer.

Best,

Elise

Elise has been fascinated with computers since she was a child. She’s worked in the field for ten years across a few industries and now works as a Senior Software Engineer. She also blogs at eliseshaffer.com.

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.

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.