Not liking my first dev job. Any tips?

Talk to your coworkers to find a mentor who can help you. I have read this story before and the folks that don't ask for help (and learn their dev tools, both standard and internal) are let go regardless of whether they want to move on or not. Difficulty navigating code is the tell tale sign - if others are being productive and you're not, ask them what they are doing and how they work. You will learn the tricks and tools of the trade.

It's fun to start new projects because it's easy and there's quick payoff. That said, no one really has a place for a serial project-starter on their team and the majority of your work in your career will be like this. Learning how to explore and modify/test a large existing codebase is crucial not only to how we work on software, but also to learn how to build (or not build) new projects from scratch in the future.

That's not to say there aren't codebases that are easier or harder to learn, shops with crappy tools, or that there aren't awesome startups doing new things all the time. If you want my advice, I'd say stick around for at least a year to eighteen months and learn how to navigate and work in a big codebase with tech debt and legacy, because when you move on to start a new project you'll know how to avoid the pitfalls or how to deal with it as it arises in that project.

The number of opportunities to build something totally green field are quite rare. Even a lot of startups are going to be using some off-the-shelf stuff to some extent just to get going.

This is true with most work. Whether it’s programming or landscape design or what have you, there is a shed load of work to do that no one is really excited about. This is why the whole “do what you love” is dangerous.

From my own experience, I find the best way to scratch this itch is to find a passion project and spend time on that as you can. This has the added advantage of getting you more time with code. You’ll pick up tips and tricks and tools.

Finally, don’t lose your optimism. Many of us work on projects that are fulfilling outside of work for just this reason.

It’s hard to avoid doing a few such stints in a programming career. Being able to navigate and wring value out of an existing code base can be a superpower at times. But don’t let this be the predominant part of your programming career.

Some tips for your current situation:

1. Accept the slowness and irreducible complexity that comes with large codebases. There is no quick fix. Don’t beat yourself up. Even people who wrote a codebase find it frustrating to come back later and make changes to it.

2. Understand the data model and the core data flows of the codebase from a business point of view. Make diagrams and notes to capture this, but do it for your own reference and not to share it with others.

3. Understand the technical architecture of the project to a sufficient extent that you’re not getting bogged down in technical questions when trying to follow the logic. This is one of the reasons that simple languages like Java or Go are preferred over more complex languages. Understand what flavor of OO or any other paradigm applies in the codebase.

4. Create a fork or branch of the codebase where you can annotate the code and add any documentation. This doesn’t need to be kept in sync with the main code as long as it’s substantially the same.

5. When you’re working on a piece, look up git blame and commit messages to see how that piece came about.

All these steps will yield results, but slowly. My feeling is that there tends be an inflection point when all the various bits of knowledge start to add up. Until then it will be slow going.

I have roughly the same background with you (self-taught, no bootcamp, freelance, etc). The difference is that I got my first dev job in 2017. What you have experienced is what I have experienced as well.

Learning and understanding legacy codebase is part and parcel of being a software engineer. So be prepared that you will take a long time, especially at the initial stage to add feature. And for legacy codebase, a lot of work revolves around maintenance, cleaning, minor improvements. While looking at it individually, it might not sound like much, but taken together, it has great impact to performance, maintainability and speed of development in the future.

What I have learn is most software engineers understand this. And they also do not expect you to contribute in terms of adding the challenging features that you talk about.

What I can encourage you to do is to ask questions as much as possible. And if you know someone in your team is working on the challenging features, maybe request to pair with the person, or ask the person if he has the time to go through what he has done with you.

Lots of "get used to it" advice here, which is honestly pretty good and honest. Like, if you were a founding developer, you'd have the joy of watching your creation turn from an exciting new thing into a legacy product. Since all products become legacy codebases, learning to work in one is vital if you want to be more than a dilettante.

With that said, don't let the passion for fun and interesting projects die! Small, start-to-finish projects are exactly what hobby, side project, and open source is for.

There's two possibilities here. One is that the code is very efficient for what it does, and the design is there as a form of bureaucracy to prevent further problems or make certain processes easy to do and bug free. Then try to learn from and understand why it's that way.

The other option is it could just be overengineered and inefficient. This is more often the case. The main symptoms are people are just creating hacks to get around it and everyone dreads coming to work. Good code feels like the programming language was designed

Often overengineering happens for a good reason. Ask why it's that way. The worst code I've seen uses "clean architecture". So I worked to understand what clean architecture was really about. Don't just say that it's bad - look at what it's trying to do and understand why that's not working or what is being implemented poorly.

In our case, the business logic was done entirely on back end, but the front architecture was designed for extensive logic, so it just led to weird situations like most functions executing only one line of code. Some things were also on the wrong layers - business logic should be below the repository layer, but a lot of it snuck in above it. Again the symptom of people writing hacks because the code was too hard to work with.

Even though you might not enjoy this, it's a good opportunity to learn why you don't like it.

I'm seeing some good advice here. I'll also say: some of this is just part of working in a large organization.

On your own or in small companies, you get requirements and you go build something. Most of your time is spent creating.

In large companies, you have to do a lot of exploration which could involve reading existing code or talking to other employees to figure out what to change. Most of your time will be spent researching and communicating, not purely creating.

New code builds on a pyramid of legacy (internal and external) code. As painful as it may be, learning how to work with legacy code is a critical skill for most new projects or features.

When you encounter issues requiring a deep dive into stack traces, you will find sloppy code that is no longer maintained and can no longer be traced to a source (frustrating!). You will also find elegant code that has worked for decades with minimal issues (amazing!).

Some advice that gets passed around and is useful - understand the database schema. For a good number of applications, if you can understand the database schema you can guess at a lot of the functionality and a lot of the code base will just be taking data back and forth from a database to either a UI or an API endpoint.

This doesn't work for all applications, but a good number.

You get paid for the pain dude. That’s what the money is for (Draper’s speech in Mad Men: https://youtu.be/w2MV-x924KA).

I can promise you any company you go to has a shitty code base. Good luck, and have a happy career.

Greenfield coding projects are very rare, except in consultancy, but even there you'll have to maintain what you build. Refactoring however can be the same type of thing. IMO use this opportunity to write tests and learn to refactor. Most developer jobs will be exactly like this, learn to embrace the suck and find the joy in the refactoring. Eventually you'll get the skills to get a better job or start a consultancy. You might also prefer being a business systems analyst where you spec projects instead of build them. IME BSAs work on a lot of the stuff you mention you like and developers just slog through the coding parts.

> I might get to add a new feature, but there's not true creation happening. None of those features are challenging or novel. I feel like I'm filling in a coloring book rather than painting on a canvas.

> … how I could pivot early in my career so that I can get in at projects inception and be a founding developer?

You’d like to skip the years of experience and knowledge and jump right into the fun parts of owning large projects and making the fun decisions.

Start an open source project and perhaps not look for your job to provide this outlet, especially this early in your new career.

First two years in the industry are literally just a stepping stone to greater things. I usually give my mentees the advice that they might as well try out some companies despite red flags because this is the time where you figure out what you don't like so you can figure out what you actually want to look for. This is also your time in the trenches as a junior dev, anyway, so might as well make the most of it!

You are missing some low hanging fruit in this legacy project you’ve been assigned. Don’t just do the boring tickets you are asked to do. Of course that’s snor city. Instead do them but then also work on little tools to make the whole system easier to understand. Stop waiting for your boss to give you interesting tickets, invent them!

Starting with a blank canvas is the exception. Most programming work is fixing bugs, incrementally adding features, adding interfaces to other systems. Only early stage startups and research projects start with a blank canvas. Even new systems in existing businesses have infrastructure, staffing and technology constraints.

You get most freedom as a solo developer, but most jobs involve teams, otherwise freelancing.

You could search for 'greenfields' in job ads, it's a common keyword for 'new systems' instead of existing large systems.

Stick with it. I had the same experience but things will get better in 3 months

This sounds exactly like me when I started my job and I was a month in. All I can say is it gets better. Give yourself some months to get more familiar with the way things are done and learn about the code.

Well, once you get more comfortable in a codebase, you will start to get a broader view of where it needs to improve. That's the point where you can start being the architect behind new creations.

That's basically the job, and it sucks a lot of the time. That's also why they have to pay us so much - otherwise, most people would just go do something else (aka golden handcuffs).

lol welcome to capitalism 101. you are a servant paid to do work no one else wants to do. your feeling is called alienation.

> I love to start with that blank canvas and through sheer will and dexterity forming it into something beautiful.

I have built many beautiful tools for clients, but there is extreme alienation when no one uses it, when you find out it's just a marketing gimmick.

love/passion is for projects you own.

welcome to the real world