|
|
|
|
|
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 :) |
|
There is a trend in our industry for each company to claim they fulfil speed,quality,cost.