10 Unspoken Truths on Being a Developer

I recently came across a series of tweets from @laurieontech that I really liked. And Twitter being what it is (an ephemeral wasteland of quick thoughts), I didn't want them to get lost in the ether.

In these tweets, Laurie presents an array of unspoken truths on what it's like to be a developer. There are some gems in here. Things we don't often talk about that are worth discussing.

Here they are, in order, with my commentary and with links to the original posts, should you choose to join the conversation.

#1: We are gatekeeping our industry

Coding is hard to learn because we've made it that way.

Without the gatekeeping there would be a lot more people in the industry and we wouldn't be in such high demand.

- @laurieontech

I don't think writing code is difficult to learn. I think that, unlike a large number of industries, software engineering is one in which there are enough resources to develop skills to break into the industry without a formal education (i.e. without spending thousands of dollars).

The problem is that breaking into the industry is incredibly difficult to do.

I can relate. When I was trying to get a job at a developer, my first employer offered me 20% less than I was making in a less technical role (marketing) and told me, "I am offering you an open door into a closed door industry."

And I'm just another white guy with a beard — someone who looks like the people doing the gatekeeping. If it was difficult for me, I'm guessing it's felt even more so among folks who don't look those doing the gatekeeping.

Still, I took that job. (I wanted the open door.) I left it after two years, and a year later I had almost tripled my salary. There is hope, for sure, but if you're in a position of power or privilege in this industry, you need to do better.

#2: Being a good or bad developer isn't about the code you write

There is rarely a situation where a developer is "bad" with code.

Almost always they can be coached.

The developers you don't want to work with are typically the ones that are unable to collaborate.

- @laurieontech

I operate within a truths I've derived from observations I've made throughout my life. One of those is that people generally want to be good at their jobs. Most people want to get better. Most people are willing to be coached (if treated respectfully).

The super opinionated assholes are the ones who aren't worth anyone's time. These are people who don't want to be helped and don't want to help. They aren't concerned with the rest of the community. And the community doesn't need to be concerned with them.

But those folks are not always the easiest to spot. Someone can seem like a dick on the surface, but have actually built up some barrier for any number of reasons. For example, I managed a mid-level developer who was overly confident and a bit arrogant for their level of abilities. They couldn't meet the requirements of the job. But we worked together and eventually unpacked that what was getting in their way was a mental health disorder that they couldn't fully control. So we adjusted their role, I adjusted my attitude when working with them, and they began to thrive.

Most people want to be good at their jobs. Remember that.

#3: Someone else's ego will make your job harder

99% of the worst parts of being a developer have to do with someone else's ego.

E.g. interviews, a list of tech you "have to" learn, criticism of perfectly reasonable code, etc.

- @laurieontech

As people get more opinionated and gain more power, they tend to build confidence alongside it. That confidence can be very good. It can also manifest itself as opinions too strongly held and delivered.

As a junior developer or an aspiring developer, if someone more senior than you appears to have all the answers, be suspicious. They are putting on a shield and using the confidence and power to steer you in some direction. That doesn't mean be a dick, but align yourself with leaders who are willing to be vulnerable. Who will pull from their experience to help you and your organization while also working to better themselves.

As someone in that senior role, don't be afraid to be vulnerable. And don't feel like you need to be overly confident. Develop the opinion, and be open to having that opinion changed.

#4: Being a developer is mostly about how you react to minor failure.

Being a developer is mostly about how you react to minor failure.

You will break things more often than you make them work.

If you can push forward towards a solution then you'll like being a dev just fine.

- @laurieontech

You're going to end up spending most of your code-writing time down ridiculous rabbit holes trying to fix bugs that make you want to bang your head against your shiny new acrylic standing desk. The part where you come up with brilliant ideas and build new apps and new features will take up much less time.

Learn how to fix bugs. Learn how to read other people's code. But, more importantly, know that everyone makes mistakes. And probably mistakes that are similar to the ones you've made.

You will introduce bugs. That's totally fine. Dust yourself off when it happens and fix the problem. Then spend a few minutes thinking why it happened and make yourself a little better.

And, seriously, everyone makes mistakes. The worst ones turn into the best stories, like this one or this.

#5: School is for theory and interview questions

Computer science programs don't do a great job of teaching people how to be developers in real live companies.

People with non-traditional backgrounds often have more relevant skills.

CS teaches you how to pass the interview.

- @laurieontech

There's nothing wrong with studying computer science in college. But it's also not necessary to become a developer. Like most college degrees, it is packed with theory and not much practical application — like how to communicate with your manager when they are being a dick.

I don't necessarily think non-traditional backgrounds lead to more relevant skills. But I do think it's good to be well-rounded. And it takes time to develop experience in how to navigate the working world, which is likely irrelevant to the thing you studied in school.

I studied civil engineering. I know talented devs who studied computer science. I also know devs who studied psychology, education, and music.

Secondary education is formal and theoretical. The real world is not. Your background makes you who you are, and you are a desirable candidate, even if it's going to take time to figure out how to pass stupid, irrelevant, technical interviews.

#6: Twitter is for developing foundational habits as a new developer

Tech twitter is a horrendous metric for determining what is popular.

It'll show you what's bleeding edge, and what might be up and coming in JavaScript.

Beyond that better to tune it out if you're trying to pick what to learn.

- @laurieontech

100% agree and not much to add. Twitter is ephemeral. It's great for conversation and for knowing what people are thinking about on the bleeding edge. It's not how you are going to build foundational knowledge on how to be a good developer (though there are a few folks I follow who are trying to help with that).

#7: Most of the code you write will be messy

You will almost never work with greenfield code.

All those awesome portfolio projects?

Ya, you're doing way more there than your average feature or bug fix.

- @laurieontech

I mentioned this earlier. Most of the code you write will be bug fixes. Laurie is suggesting here that feature work will be a big portion, too. But not greenfield applications.

Once, when trying to find out what made a direct report tick, I had this younger developer tell me, "I want to greenfield an application."

It's sounds fun, and it is fun to get started. But it becomes dull and bulky and difficult to maintain far before it is useful to anyone. Even your greenfield applications turn into feature work and bug fixes.

And that's okay. But set your expectations appropriately. Most of your time is going to be maintaining and improving, not starting from scratch. And that's good! The times in my career I learned the most were when I was forced to work with messy codebases that someone else created.

#8: The more "senior" you get, the less you'll code.

The more "senior" you get, the less you'll code.

You'll sit in meetings, create architectures, help other debug, do research on new potential tech, etc.

- @laurieontech

Oh it's so true.

But! It doesn't have to be true.

As you become more senior, you're going to be asked for your input more. You're going to be asked to think more than build. And that's okay. The work has to begin somewhere and it's a good feeling to be the one guiding that work.

You'll probably also be asked to manage, or at least mentor, other devs.

All of that is okay. Great, really! If it's want you want to be doing.

If you want to keep writing code, you can absolutely do that. Your career options may be limited, and you'll inevitably still get pulled into those high-level meetings. But you can do it if you want to. It's just a little more limiting and difficult to maintain.

#9: You can be a generalist or a specialist

You're never going to be an expert in everything, or even most things.

Companies that want you to be a hero and "just make it work" are in for a world of hurt when stuff breaks.

Find the expert when you need them.

- @laurieontech

I took this one in a different direction. I do agree that you can't be an expert in everything. But I think you can also choose if you want your knowledge to be wide or deep. To be a generalist or a specialist.

Smaller companies often want generalists — folks who can be relatively successful with a lot of different responsibilities in a lot of different areas. In my first two months at Grouparoo, I made a video, wrote documentation, fixed a few bugs and added small features, wrote a blog post, and consulted on building a community.

But, if you're going to generalize (which is fine), it's important to know when something is out of your wheelhouse. Or even when it would be more valuable to hire an expert to help. For example, I know a lot about SEO. But not enough. And I don't really like doing it. So, whenever it comes up in conversation, I typically suggest we hire someone to help do research and run reports. Someone who does that all day every day. Because we'll get much more value that way.

#10: The best tech companies are rarely the ones you've heard of

The best tech companies are rarely the ones you've heard of.

- @laurieontech

I don't have a ton of experience here, so I'm going to take Laurie's word for it. What I know is that I much prefer to be at a small company where I can be a generalist and have more influence. I despise the policy-for-policy's-sake that comes with many larger organizations. And I don't like feeling like just another cog in the wheel.

As a result, I've spent my entire dev career working for companies you've never heard of (unless you've heard them from me). And I've done that because they were really great places to work.

There's probably something else to explore here in considering why this feels like a truth. Is there something about becoming known that makes an organization less desirable?

I don't think I know the answer. What I do know is that you can build a perfectly successful career at organizations that the larger community doesn't know about.

And that's fine. Your path is your path and you are you. Be the best you that you can be. Keep fixing bugs. Keep learning. Be vulnerable. Be yourself. You are (or will be) a great developer.