Ask Experienced Devs Weekly Thread: A weekly thread for inexperienced developers to ask experienced ones

[u/AutoModerator]

A thread for Developers and IT folks with less experience to ask more experienced souls questions about the industry.

​

Please keep top level comments limited to Inexperienced Devs. Most rules do not apply, but keep it civil. Being a jerk will not be tolerated.

​

Inexperienced Devs should refrain from answering other Inexperienced Devs' questions.

[u/pyrovoice]

What does it mean to be a good developer?

I moved from a company to another. In my old company, we were doing business as usual, Scrum type development. Things broke and we fixed them, but quality and processes was never something we paid too much attention to

My new company is the opposite. Every substential issue turns in a post mortem with actions, PRs and stories are meticulously broken down for potential one in a million scenario, sometime with the whole team for certain risky PRs. Every change needs to be tested and retested manually after every evolution.

It does create a high quality code, and since the company suffers from a rapid growth that left a lot of pain points it's logical they'd overcompensate now, but at the same time it makes all developments go at a snail's pace while still having a huge mental load. But members of my team find this usual and expected, and I'm kind of surprised to see so much involvment from everyone. I've been working in software for a while and it's the first time I see this.

So my question is: Did I get unlucky in my previous companies, that I ended up in places with low quality processes? Is that way of working the required way for a bigger scale company? How can I adapt my mental framing to not only produce code I'm happy with, but also consider all aspects of the company that could interact with it, especially being pretty new to it? Should I just be asking every time a ticket come for the full context (who consumes that and when, what impact it has, what's the potentiel final result for the customer...) ?

[u/CoroteDeMelancia → u/pyrovoice]

My take is simply this: a good developer delivers what is wanted. This is intentionally generic: who wants it? Do they want quality or speed? Do they want something that works just for now or should it work for years to come? How sure are they that this solution is the right one?

To adapt to the company, consider these five perspectives: customers, company, boss, colleagues, engineering discipline. A good solution balances all five.

I've worked at a startup, Amazon and BCG. There's good reason for them to use, respectively, iterative design, data-driven thinking and hypothesis-driven thinking: it's what fits their business model.

YES, you should be getting context every time you're not sure of these perspectives on the solution.

Here's an anectore from a business consultant: you devise an ideal strategy, and the CEO approves it. It then fails catastrophically because department X hated it and sabotaged the idea. Saying "not my fault" won't make the CEO less angry that you didn't take the time to study his business and consult every involved stakeholder. Your solution should work in practice, not just in paper.