Hacker News new | ask | show | jobs
by thiht 424 days ago
Our job is programming. I regularly see opinions that "90% of our job is not programming" and I don’t relate. Sure, our job is not just programming, but honestly if you don’t spend at least 50% of your work time programming, there’s something seriously wrong in your organization.
3 comments

What is "our" job in this context? For example, when I was a junior over 50% of my work was literal programming, but as I get more senior I program less and less.

From my perspective "our" job is to deliver solutions to specific problems our end-users have. How people accomplish that varies a lot by their position/seniority.

To get into the weeds: When I first stared worst case scenario, I could waste my own time with poor or overengineered solutions. Now I can waste half a dozen programmer's time by not doing enough due-diligence and or planning.

It really depends on your role. I still think our job is ultimately to solve problems for users and/or other stakeholders, and that coding is just one of the tools we use.

But it's not always the best tool. Even as an IC, I've done far more with emails and meetings than just writing code without thinking, whether that's discussing UX implementation details with the designer or pushing back on some half-baked over-engineered solution from management or fighting some evil advertising and tracking scheme from marketing. We don't just write code but also gatekeep it with some level of professional judgment and ethical discretion. (Or at least should.)

I think the orgs that don't give you any autonomy or agency beyond "code monkey" are the more problematic ones. Not only will you burn out having to repeatedly implement things you have no input into, you'll also be the easiest to replace if all you do is code.

> ultimately to solve problems for users and/or other stakeholders

Doesn't this describe every job on Earth?

To some degree, yes, and I'd hope that other skilled professionals would take a similar approach.

Like if I wanted to add EV charging to my home, I'd hope the electrician would take the time to explain the different levels of charging, the breaker and wire upgrades needled, etc., find a suitable installation site around the house, etc., not just start hooking things up willy-nilly. Or that a HVAC person might talk about the pros and cons of heat pumps, or a doctor might discuss different treatment options, etc.

It's different from, say, being a line worker in a factory assembling the same part 10000x a day, or a fast food worker.

Sure, at some level we're all just "solving problems", but I'm arguing that a good dev thinks about the problem and possible solutions as a whole, and utilizes that agency to make the final output better, instead of just coding Jira tickets to spec and never saying a peep.

But that's my own bias as a predominantly frontend person working for small or medium sized companies where specialization isn't as extreme. Maybe at bigger companies and teams they already have many layers of UX/UI/design/management and don't need (or want or appreciate) a dev speaking up about any of those things. In my experience it's never that black-and-white and a lot of tickets and designs are ambiguous and require both professional judgment and some empathy to implement well.

Maybe that's why I prefer the generalities and of the frontend vs, say, hyper-optimizing a very specific database call.

100%. To an extent that's why I don't often freelance anymore as it's very easy to fall into a place where e.g. to build a booking app for a pet shop you need to become an expert in the field of veterinary.
Heh, it's funny, my partner is a vet tech and I keep thinking how interesting it would be to build a CRM for them and their patients (there is already an industry for that and some of the apps are actually decent).
Not everyone is cranking out boilerplate web services/web apps