There is an interesting shift that happens when you transition from a junior to a more senior level engineer (or any other career for that matter).

Note: You’ve probably met 40 year old juniors and 20 year old seniors, age has some correlation, but less than you’d expect.

I’ve had a self-driven approach to work for many years. I started my own company when I was just in my first year of uni. I was self employed for quite a few years (tutoring), and I’ve worked on multiple software projects with other people.

But work is different.

Back at Decipad (my first real job), I was a junior. Sure, I knew how to code but did I know how to be an engineer? I didn’t.

As months past I got very good at being self driven. From figuring out what the product needed, to discussing it with the team, to implementing it, to delivering it, to maintaining it. This is something I am very grateful for having the freedom to do when I was working here.

Now that I am at Requesty, I’ve had to relearn this.

Everyone is a junior when they first join.

OK. Maybe that’s not true but stay with me.

When you first join a software project, you don’t really know what’s going on. You don’t fully understand the customers, you don’t fully understand the product, and you certainly do not fully understand the code. So what can you do?

You can do tasks. And ask (many) questions.

You shouldn’t be responsible for the full delivery of a brand new feature the moment you step foot through the door. Your job should be to learn as much as possible. Contributing will come.

Take Accontability

When you’re more established, you understand this new place a little better, then you need to turn your engineering brain fully on. You need to understand that you are not here to be a ticket crunching machine. You are an engineer!

What do I think an engineer (in a software company) is? Well, it’s someone who writes the code, tests it, makes sure it goes into production without breaking other parts, makes sure it actually works, makes sure it was worth building in the first place, goes back to improve existing code and infrastucture, someone who can talk about the business requirements and the more abstract concepts surrounding the code they write (or tell an LLM to write).

The reason I’m writing this blog post is because this part is hard.

Writing code is many (maybe all?) engineers confortable place. We like writing our tests, watching the screen go green as we make them pass. We like taking some code and refactoring it to look nice and pretty. (At least I do).

But then what?

You must go beyond this. You need to lead the way. You shouldn’t be just the tool your manager uses to spit out code. You should be the person your manager delegates to, to fully build something.

How does this have to do with accountability?

If no one is telling you what to do, or how to do it, what do you do?

It’s not easy, and often we are not as self monivated as we would like to be (I know I sometimes lack in this regard). But you need to turn your engineering brain on, and figure things out. You need to know what to do next, and how it will impact the business and other people around you.

It isn’t enough to sit back and write code. That code needs to be in the hand of customers, it needs to be tested, it needs to be deployed, maintained, it needs to be designed. It needs love and attention.

My conclusion

Take accountabiliy for your projects at work. You need to be able to lead from start to finish. You cannot wait for someone to tell you what the next step is. You need to figure out that next step.

Now, I talked a lot about you, but I must stress. If you cannot go to your team to share opinions and ask for help, then you need to leave whatever company you’re working for. We’re very much shaped and pushed by those around you. And part of this concept is that you need to help others too, in a funny way, you need to know when to help others!

Writing code isn’t enough. Be an engineer!