←back to thread

122 points foxfired | 2 comments | | HN request time: 0.407s | source
Show context
mcv ◴[] No.43565395[source]
I wonder if the fact that we're not hired to write code, is also the reason we're not paid as much as some other roles. This is my big frustration: that senior programmers (in NL at least) are not paid as much as managers, POs, various kinds of architects, and even scrum masters.

A couple of years ago, I was freelancing for a company where I wrote a lot of excellent code. They had a bunch of data they wanted to do something with, but weren't entirely sure what or how, so I did that for them. Connected, visualized it, made it fast, and they loved it. And so did I. It was fun work, I talked to a lot of people about what they wanted and needed, and delivered that.

My freelance period ended, but I wasn't ready to leave this project yet, so I became an employee, but that turned out to be a massive step back in terms of income. Despite the fact that I worked closely with lots of stakeholders and solved complex problems for them, their internal rules didn't allow them to pay me as more than a code monkey. I felt all the non-code work I did wasn't being appreciated. Nor the code work.

I left, they ruined the application (it's apparently slow as molasses now), and now I'm about to go back. I guess I've made peace with the fact that they don't pay programmers as much as I think they should. (It's not actually bad pay, just not as much as non-programmers get.) But mostly, it was a fun project that taught me a lot, and I want more of that.

replies(4): >>43565900 #>>43567473 #>>43573702 #>>43577046 #
aaronbaugher ◴[] No.43573702[source]
I think it's easy for the decision-makers to take programming talent for granted because they can't see it or estimate what it can do. If my manager comes to me with a task, he may not even know if the task is possible. If it turns out to be relatively simple and I kick out the solution in an hour, he's impressed, but he's also "learned" this this stuff is easier than he thought. That shifts his mental window of what's possible in X hours. Every time he thinks, "That must have been easy after all," the more he's likely to devalue what he thinks the work should cost. A smart manager will know better, but many don't.

We could combat that tendency by taking a longer time than necessary on some tasks, basically loafing to make our work look harder, but who wants to play that game?

replies(1): >>43575489 #
mcv ◴[] No.43575489[source]
Instead of loafing, you could also collect more context. Talk to various stakeholders to better understand the context of the problem. Read about company policies or market developments that made this necessary.

Boring stuff, I admit (the reading at least; I enjoy talking to stakeholders), but it can give you a much deeper understanding of what you're working on.

replies(1): >>43577056 #
pdimitar ◴[] No.43577056[source]
I agree with your advice but have to remark that often times stakeholders are not open to talk to techies. I loved those who were but most weren't.
replies(2): >>43577550 #>>43580076 #
1. mcv ◴[] No.43580076[source]
Then don't tell them you're a techie.
replies(1): >>43587661 #
2. pdimitar ◴[] No.43587661[source]
Pretty difficult when you are hired as a programmer and are introduced during an all-hands meeting. :D