Hacker News Reader

Comment by capote | Hacker News Reader

> Engineers are hired to create business value, not to program things

So is every employee of every company. They create business value by doing what their role is. This is the point of a company, this is how it's always worked. The role of a programmer is to program things. So a programmer programs things, and that is what they are hired for.

Why do we constantly get blog posts discussing ridiculous semantics like this?

Sure, it might work for some companies, but that's so utterly unimportant. I'm a programmer, I tell people I'm a programmer, I'm paid to program business applications, and I'm happily employed and liked by my superiors and company. Clearly this line of thought also works fine.

So maybe the best advice is to just do what you do, call yourself whatever, and cut it with these self-important blog posts preaching your way to everyone else as though it's some holy advice on cracking the employment puzzle.

View on HN

Semantics matter. Especially when you're trying to sell something, such as your skill set. Ever had to lobby your idea or project to a non-technical decision maker? You can't whip out the technical jargon and explain in minute detail why your solution is obviously the correct one. The non-technical decision maker is going to gravitate toward the option that is wrapped in the most appealing narrative - hence the semantics.

That's great that your happily employed and are well established in your company. I'm not. And a big junk of the problem is because of what Patrick discusses in that post. I'm an engineer who was hired to work in what is perceived as a cost center. Because of that, many of my solutions to problems are only allowed to be half implemented or they slide lower and lower down the priority list as more urgent tasks come up. The only reason they're more urgent is because someone can directly tie them to making money. Telling someone you "program" things doesn't tell them what value you bring to the table.

I wish I'd read this post 5 years ago when it was published and I might not be in such a sticky situation.

> Ever had to lobby your idea or project to a non-technical decision maker?

This is actually my job; I'm an architect and I interface a programming team with non-technical superiors (I simplified my position previously to make a point).

Part of my spiel in talking to non-technical superiors is being straightforward and bullshit-free. If something's a program, I call it a program, not a solution, business lalaploo, schpleplipagan, or quilbilbalala wrapped in bacon. It's a program, and it's programmed by programmers who are hired to program and spend their time programming. My non-technical superiors cherish this directness and lack of semantically loaded garbage. They "gravitate" towards the most clear and well-put solution, and part of that is not to wrap it in any narrative whatsoever, but to tell them straight up what the situation is. By wrapping something in a narrative, and trying to make it seem more than it is, it starts sounding less like professionalism and more like philosophy, and you instantly set off my bullshit detectors (and those of my superiors too). It starts smelling of indirectness and ulterior motives.

And this goes the other way too--when hiring someone, I'm hiring a programmer. Not an artist or philosopher who can tell me what silly billy value they add to my company. I decide what value they add; if they add any at all, it's the value of the programs they program (don't take that the wrong way--this is a lot of value, and I appreciate it fully, but it's still programming programs--the programs are the vehicle with which they add value).

I'm at a rather large company and management doesn't understand enough about what they're doing to know exactly what provides value and what doesn't, much less who is providing that value. I'm guessing once a company reaches a certain size, a lot of that becomes illegible.

I prefer to be direct and as clear as possible, but that hasn't been what's gotten me results. I watched how others (more senior engineers) were able to influence decisions and found that they were some of the best bullshit artists I've ever seen. So I adapted how I communicated as much as possible without compromising my ethics. I'm leaving my company, hopefully to join a company more like yours.

Patrick's advice hit pretty close to home for me.

Yeah, maybe I do lack some perspective having never worked for a truly giant company. My parents both work at massive banks (in technology, in fact, my dad has almost the same job as I do), and a lot of what they talk about is how much politics they have to do on a daily basis that has nothing to do with their job, but rather just appeasing golden retrievers with treats and belly rubs.

But then, this goes even further to show how every situation is different and there's no umbrella of advice that works for employment.

You should of course do what you believe is best for your situation.

Patrick's observations are still useful, though. The semantics aren't ridiculous. They're a very real distinction, and they matter...especially if you're looking to move into contracting/consulting. If you find yourself doing that, it helps if you can position yourself farther up the value chain. In this situation, it helps to be able to describe yourself who understands business, communicates well, and can talk to a customer, understand their problem, and solve it. Having the ability to understand a business's problems and create software to solve those problems can give you a pretty significant advantage.

But this means you're not a programmer. If you understand a business's problems and create software to solve those problems, you've already moved higher up in the ranks than a programmer, so of course, call yourself whatever your title is (architect, engineer, director, whatever).

> Why do we constantly get blog posts discussing ridiculous semantics like this?

Because many people (especially early in their careers) don't understand that. I didn't. I was hired to program, so I'd program, but I had no idea what the connection was between my work and people sending the company money.

That sounds like a bigger issue--being oblivious to what your role is/how companies work. No amount of re-naming/re-titling yourself will fix that. A name is just a name; it's what you do that matters.

Reply on news.ycombinator.com