First dev job, boss discouraging me from using best practices to save time | Hacker News Reader

First dev job, boss discouraging me from using best practices to save time

4 pointssluttering4 comments

I’m worried about where I’m at right now. I got a job as a junior dev and I’m super excited however my boss gets annoyed with me when I take a little bit longer on a project for implementing things like error handling and sanitizing inputs, etc…

I’m worried that it may stunt my progress. I know I’m new but my philosophy is to build something right and right the first time and so I don’t have to go back and fix a buggy app for six hours when the problems couldve been avoided with an extra 2 or so hours of development. Idk I just feel strange because I’m so happy to be working in development but I’m having a lot of trouble with the whole “put it out as soon as it meets the e minimum threshold mindset”. Am I off base, I mean I still am a junior developer so maybe I’m just expecting too much?

View on HN

It's impossible for us to give you a good answer from outside your company.

Sometimes, "best practices" are pure waste. Sometimes they are even counterproductive. Sometimes they will pay off immediately. Sometimes they will pay off for the company, but only after the current team has left and won't receive credit. Sometimes they would pay off for the users, but the company doesn't care about their users.

If possible, discuss the issue with a senior engineer (or two) on your team.

I would not get too confrontational with your manager. At the end of the day, your customer is your employer. But keep a note of the compromises that you're making, and remember if they cause any problems. Determining when to cut corners, and when to break out all of the formal methods, is an important part of your maturation as an engineer.

First, congrats on starting your new career!

I’ve been a dev for over 20 years and trucking on still, so I can give you my 2 cents.

If you’re just starting out, your boss ought to be taking a more ‘mentoring’ style with you. Your reasoning is fair, and taking care to do things right is a good philosophy. However, there’s often a balance between time sensitive deadlines and doing things rigorously in development. Knowing what compromises you’re making as a developer and why you’re making them is something that comes with experience. Essentially, we’re making design decisions in the interest of time. As a manager, I’d be uncomfortable expecting a junior dev to get this right, but the fact you’re aware of the right way to do it, and what you’re being asked to do is a compromise, is a good signal that you’re a good developer . All my developers had their own ideas of how to do things and discussing whether a particular idea was worth the risks it brought to the deadline was all perfectly normal, reasonable and expected. Just normal project management mojo. So long as you and your boss can have productive conversations about your concerns, I wouldn’t be too hasty about leaving.

I’d suggest you learn what you can where you are, realise what’s missing from your current role and keep an eye out for other job opportunities.

> build something right and right the first time

It sounds like you expect everyone to share your definition of right.

And for that definition to be stable over time.

Things change. When it's a greenfield project, the quality focus is on developer experience and getting that MVP out the door. Once it's an established project, the quality focus is performance, security, regulatory compliance, etc. The very notion of quality changes depending on the lifecycle of the project. The environment you wrote your code in will not exist for long! New bugs, new priorities, new business pressures, new features, cross-functional changes to support other projects, tech integrations, refactors ... the long-term success of a software project is overwhelmingly defined by its ability to handle changes gracefully.

There are two philosophies on how to tackle this:

1) Invest now in quality: hope that you've anticipated most of the future pressures and that your efforts are not wasted. Knowing why other software projects fail gives you a roadmap to avoid the same problems.

2) Invest later in quality: hope that, if the project is a success, it will provide resources to iteratively improve quality. Knowing that most software fails, it makes sense to invest only after it's achieved a modicum of success.

Sounds like you're firmly in camp #1 and your org is in camp #2. Both camps agree the goal is reasonable quality + high perceived end user value ...you could approach the conversation as a (constant) negotiation to define what "reasonable" means. But always keeping in mind that your personal definition of quality is subjective and subject to change.

Reply on news.ycombinator.com