Hacker News new | ask | show | jobs
by telebone_man 3125 days ago
Considering my whole career, I'd say you should probably get used to it and evolve!

I don't mean to sound defeated. Sometimes projects are done 'properly'. Documentation... Good code over 'code that just works'... etc. But sometimes the business need to just get something released can outweigh that.

Picture this - the business has an opportunity that will generate £x in revenue. This revenue will ensure your job. It'll contribute to the coffee you get to drink. And other benefits you might take for granted. The catch is, the code to fulfil this opportunity needs to be written in 3 months when you know that it should take 9.

This situation just requires a different way of working. And a different set of skills. Such as understanding the requirements to a tee so that you can produce the absolute minimum. Delegating where possible (such as letting others do the testing - if they're doing that badly, that's not your problem). I'd say over time I've gotten better at reading code that isn't commented. (hint:learn how to use a debugger for your given language). I've also gotten better at writing short snappy docs.

To answer your queastions directly, again across my career... - Tech stack is normally 50/50 modern and legacy. - Both the modern and legacy languages/frameworks/tools fulfilled the end-user requirements set out in the first place. - Common practice is 50/50 people who care about their job and those who just want the paycheck. - 75% ask for advice on architecture from the 25% that can do it well. - Culture is what you make of it. If there's no scene, create one. (just like punk music). - People only communicate when they need to - Deadlines? Yes! They're normally not met though. See above! - Management reasonable? Subjective :)

2 comments

I think you make some excellent points. I think the oft mental block engineers stumble into is that management are often not clear in articulating that speed for a certain project is more important than reliability or quality for example.

There is a trend in our industry for each company to claim they fulfil speed,quality,cost.

To the OP, if you're one that "cares" about the job and want to be one of the "25% that gets asked" then your current position does not sound like a good fit.

One plus side: based on your experience in this company, you probably know more about what to look for and ask about in future interviews.

You might want to look at joining a smaller company. That probably means less job security but a better engineering environment. (then again I'm biased towards smaller companies).