50 Things I Wish I'd Known at My First Developer Job (Part 2)

This is part 2!

26. Culture fit is dangerous

Culture fit might be one of the most dangerous concepts in any hiring process.

My first job included a pretty stringent culture fit interview in the hiring process. It sounded like a good idea; they told me that they wanted to make sure I'd fit in with the team (ironically, I didn't at all).

Ascribing to the idea of culture fit is probably the single most effective methodology for creating a monoculture. If I try to ensure that everyone fits in with the team, I'm excluding those who come from a different background as a practice. Culture fit is the enemy of diversity.

I wish I had challenged the culture at my first job, that might have made it a radically better place for me.

27. Programming languages don't make you smart

When I first started programming for money, I felt like all of the best developers in the world were writing in cool, trendy languages.

I thought that Rust developers and Go developers were the top of the industry and that people writing PHP were probably stuck in that language and unhappy.

That's a toxic mindset, and it is wrong.

People use the tools that work, and the tools don't denote someone's intelligence or ability. There are world-class programmers writing PHP, Java, and all manner of other "undesirable" languages.

28. Frameworks are flexible

I joined a Ruby-on-Rails team at my first job. While I was learning, I viewed Rails as law; written in stone.

It took me a very long time to realize that a framework is just code. Code can be changed and even circumvented when it's necessary.

Had I realized that frameworks were flexible, I might have gotten started contributing back to Rails much earlier.

29. Your stack isn't the most important decision

Like the stupid belief that programming languages are related to aptitude or intelligence, it's dumb to think that the tech stack of a product is the most critical decision.

As a matter of fact, when it comes to a product, this might be one of the least important decisions you could stress over.

30. Your network is your most valuable asset

It's not what you know; it's who you know. This is true.

Learn to network; you'll thank me for it.

31. You are valuable

In my first job, I always thought I could be replaced at a moment's notice.

The truth is, just by knowing how to build a basic UI with HTML/CSS and a sprinkle of JavaScript, the market has determined that you are extremely valuable.

Learn to own that truth because it will help you to feel empowered if you need to walk away from your job. I would have left that first job so much earlier if I had realized that my skill set was valuable.

32. Software development takes time

It's easy when you're new, to be over-eager and promise unrealistic results. I frequently got myself into hot water by assuring others that things would be done much earlier than I should have.

Learn to estimate, and when in doubt, rely on Hofstadter's Law.

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

Good software takes time, and if I had learned this sooner, I would have written a lot less bad software.

33. You will get better at solving problems

I've noticed that juniors and interns tend to feel exhaustion at the end of a workday literally. The mental overhead of learning so much and talking about all these arcane concepts that make up software engineering make your brain feel like mush.

This will pass. I had so much anxiety over this feeling. I'd come home at 5:30 in the afternoon and fall asleep for 12 hours. I thought that my entire career would be a cycle of work and sleep until I died.

In reality, your brain gets more resilient the more you do this job, and by the time you've been doing it a couple of years only the most dubious of problems will make you feel like a zombie.

34. Whiteboarding is toxic

I have a lot of opinions here, but I got whiteboarded a lot, and it made me feel stuck in a job I hated.

Managers: Don't whiteboard people. Applicants: Refuse to whiteboard.

If a company relies on this tactic to hire their employees, there is a good chance you don't want to work with those employees anyway.

35. Writing bad code doesn't make you stupid

I used to feel really bad about myself when I wrote bad code.

I'd make a PR, and it would get torn to shreds, so I would go home and feel sorry for myself the rest of the evening.

When you write bad code, acknowledge that it is the result of ignorance, not stupidity, then take the advice that is offered to you.

Remember, you should always assume others have the best intentions.

36. Make time for yourself

This is something that I still struggle with, but I don't need to give much more evidence to this than the obvious.

When you're struggling with a problem for hours on end when it feels like you're swimming through half-dry cement, you're not getting closer to a solution, you're just getting exhausted.

It always seems like the solutions to that kind of problem come hours later in the shower or at the gym. That's because taking a break gives you time to process and lets you take a new perspective. Taking a break will help you solve problems faster.

Don't work 90 hours a week just because you think it will make you more productive. I'm speaking from experience when I say, it won't.

37. Read fiction

This goes along with making time for yourself.

As engineers, we are always consuming information. Usually, it's technical information or biographical information about the industry. While that is useful information to have floating around in your head, it's not the most conducive to creative thought.

What developers do is inherently creative; we must be exposing ourselves to other creative things. In my opinion, one of the best ways to do that is to read fiction.

For the first year of my career, I avoided fiction like the plague because I was so focused on reading only technical content. That sapped my creativity, and now I try to keep one fiction book in my rotation at all times.

38. Listen actively

If you're not familiar with the idea of active listening, you need to get it locked down now.

A massive piece of what developers do is directly related to understanding other people well. We have to be able to translate feedback into useful features, and that requires some world-class listening skills.

Do yourself a favor and read How to Win Friends and Influence People while you're at it.

39. Your opinion matters

When I was new, I always thought my opinion was the least important one.

That wasn't true for me, and it's not true for anyone reading this, as humans, we all have unique backgrounds and experiences. That means our perspective on any given problem is different, so it's crucial that we speak up when we have thoughts.

40. Seniority isn't everything

It's tempting to look up to your senior coworkers and think that they've got everything figured out.

I rushed to try and earn that senior title because it felt so incredibly important to me, but in reality, the title is so subjective that it's really not very important for anything other than the resume bullet.

If I could go back in time, I would tell myself to slow down and use the early days of this career to focus on learning. Seniority will come when it is time.

41. There is nothing wrong with being a slow learner

I'm actually a swift learner (probably slow compared to many, however), but I always worried about being perceived as a slow learner.

Over the last couple of years, I've learned that slow learners tend actually to know subjects much more thoroughly than I do. In fact, once or twice, I've found myself wishing I was better at slowing down and focusing on details.

42. Software engineering is an endurance sport

Like I said before, building good software takes time.

Building a career in software takes a long time. Endurance over a long period is much more valuable in software than a short burst of effort.

I don't like the term "sprint" for this very reason.

You can't build Rome in a day.

43. Software engineering is a team sport

Software engineering folklore would have us think that individuals ship great software. We hear names like Lovelace, Wozniak, Torvalds, Turing, and Hopper all the time. We believe that those individuals have achieved amazing things in the computing industry, but we fail to think of the people that supported them through their projects.

All great software is built by teams of people, directly and indirectly.

I dreamed of herculean efforts when I first started writing code, and I wished I could go away for a week and come back with hundreds of thousands of lines of untethered brilliance. Unfortunately for my ego, it just doesn't work that way.

You can't build Rome by yourself.

44. Use tools that you love

Few things get software developers riled up like their tools.

Go find some old forum threads about Emacs and Vim or step into any discussion of programming languages. You'll discover quickly that developers care immensely about their tools.

You should, too, and you should take advantage of that deep interest in tooling to excite yourself and challenge yourself to learn your tools more deeply.

The moment I realized that I liked Emacs, I started learning so much more about how my environment worked. I grew a lot, just because I got excited about a tool.

45. Use tools that your team uses

Don't become a zealot. I love Spacemacs, and I will probably always have it installed on my machine, but I also install the most popular text editor on my team so that I can pair program with anyone on my team.

46. The shell is your best friend

A lot of beginners are intimidated by the shell, but if you really take the time to get to know the shell, you'll realize that it's an excellent tool for automated your workflow.

It took me a long time to get used to the shell, but once I committed to it, I felt much closer to my machine. It helped me to understand my OS rather than feeling limited by the UI of the tools I felt like I was working alongside my machine.

47. Googling stupid things is normal

At my internships and my first job, I felt a little embarrassed when I had to Google simple things. For example, I always felt like it meant I was in over my head when I had to Google the syntax for SQL queries.

These days, I've come to realize that even the best engineers Google stuff pretty much every day. No one can hold this entire profession in their head, lean on Google when it makes sense. Save your brain space for the important stuff.

48. Seniors aren't always right, and they don't know everything

When I started in a junior role, I always thought the seniors on the team had everything figured out, but I've come to realize that senior engineers are just people who have failed more times than I have.

It's also important to challenge your senior coworkers if you think you know something they don't because there are without doubt things you've been exposed to that they've yet to see.

49. The loudest person in the room isn't always right

As an industry, we have a nasty habit of trusting loud people. I've benefitted a lot from this in my career because, as my friend Jared once put it, I've got a tall personality.

If I could go back in time and tell myself to question those people who seem the loudest more frequently and to avoid being that person when it's inappropriate, I would.

50. Diversity makes everyone better

I've always cared about diversity, but I didn't see the real benefits of diversity until I started working in Open Source.

A diverse group of people makes better decisions than a homogenous one, literally every time.

This is something I should have embraced earlier and tried to champion back when I first started.

Again, this is a list intended for me when I was new. It won't apply to everyone, and most people probably don't need to hear this advice as much as I did when I first started writing software, but maybe a few people will read this and benefit!

There's more...

I'm writing a lot of articles these days, I run a podcast, and I've started sending out a newsletter digest about all of the awesome stories I'm hearing.

You can also follow me on Twitter, where I make silly memes and talk about being a developer.