Live data from Hacker News

Ask HN: Not liking my first dev job. Any tips?

news.ycombinator.com

11–20 of 32 posts

Re: Ask HN: Not liking my first dev job. Any tips?

#11

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!

Good suggestion! I'm just a little skeptical as the job is remote and paid hourly. I submit my hours at the end of each week. I don't want to submit my timesheet and then be like "Oh hey yeah by the way these X hours are for something completely unrelated to what I was assigned. Hope that's okay." If it were salary based or something else I'd be totally willing to dive in but as is I don't want to ask to be paid for…

Do something small, submit on your timesheet, and then ask for feedback. If they don't like it, it's just a couple hours, so less of a big deal than a couple days or weeks of work.

If you ask your boss for feedback on what's possible to submit on a timesheet, I'm pretty sure you're guaranteed a response.

Re: Ask HN: Not liking my first dev job. Any tips?

#13
> 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.

Re: Ask HN: Not liking my first dev job. Any tips?

#14
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.

Re: Ask HN: Not liking my first dev job. Any tips?

#15

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!

Good suggestion! I'm just a little skeptical as the job is remote and paid hourly. I submit my hours at the end of each week. I don't want to submit my timesheet and then be like "Oh hey yeah by the way these X hours are for something completely unrelated to what I was assigned. Hope that's okay." If it were salary based or something else I'd be totally willing to dive in but as is I don't want to ask to be paid for…

I consider refactoring as part of the job and submit it on the timesheet. However, be careful because as a junior you might be approaching it the wrong way.

Re: Ask HN: Not liking my first dev job. Any tips?

#16
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.

Re: Ask HN: Not liking my first dev job. Any tips?

#17
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.

Re: Ask HN: Not liking my first dev job. Any tips?

#18
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!).

Post reply on HN