If this is good for a career? Don't know don't care. It's what I do and enjoy, and there are many slippery slopes to not coding and becoming rusty, and ending up on the M train by default.
I work on a team of 50 employees. For those 50 people, there are two managers. 1 out of 25 isn’t great odds of being accidentally promoted into management without your consent.
Your working style may be right for you, I’m not questioning that. But in a thread targeted at career advice for junior engineers, I thought it’d chime in from the other side. The chances of accidentally ending up as a manager are very slim. Don’t destroy your career and miss out on interesting opportunities to avoid something that’s not likely in the first place.
Where I work it's about 8/50.
But I don't have to worry about being a manager - because they only get hired from outside.
Firefighters don't call themselves ladder and hose operators. Those are just the tools they use. Their job is to fight fires so they call themselves firefighters.
There's no standard terminology and nearly every company has a slightly different definition of terms.
The important question would be "is this work useful," not "does this work involve capitalism."
https://www.railinc.com/rportal/documents/18/260737/CRB_Proc...
I live to build things and continuously fend off attempts to slide me into management, but I find actually programming things to be only half the part of the puzzle.
Humans are extremely bad at articulating what they want and will generally tell you the wrong thing up front because they haven't thought it through fully.
A day spent with a stakeholder carefully picking their brains and properly crafting a plan can be just as satisfying as a day of straight coding - sometimes more so.
(tbh this is probably also why I find UX work so interesting - getting a user to click on a button is considerably harder than making the button in the first place)
>How do you know what to code
Someone need something to be made or done, I help them by writing code.
>whether you should even be coding
I've been doing it for long time
>if you aren’t willing to spend the time knowing the business and the customers?
That's precisely the reason I prefer code. I'm not that interested or even willing to spend time knowing the business and the customers.
Then, another developer who had been there for a decade asked me how I would go about writing “address validation routines” - It was a real world problem he was facing. I told him that I wouldn’t. That’s not the vertical the business was in. The best code is the code that you don’t have to write. Address validation software is a solved problem and there are plenty of third party CASS solutions and yes they cost money but being able to write address validation software is not the company’s competitive advantage or its differentiator in the market. It’s better to outsource it. That’s one less thing we would have to maintain and debug.
The developer wasn’t impressed. The CTO was.
I’ve spent my entire career asking questions and making sure we were building the right things.
My first job out of college over 20 years ago I was the sole developer on a project to write a data entry system that was used by a new department with a dozen new employees. I had to actually talk to our potential client to gather specs myself.
But this gets back to what OP was saying. Spending time asking questions == spending time in meetings. Not writing code.
I’m not advocating for never asking questions or suggesting better ways, just saying that I prefer to work where someone else handles the bulk of that so I can focus on what I specialize in.
But how to know what to solve... At least for my job, interpreting customer requests is key. The customer knows what they want, but they don't always realize what they want is not the best solution.
Often I can steer the customer to a vastly superior solution to what they initially had in mind. Not seldom this superior solution can re-use existing code, sometimes entirely.