4 ms·

> 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 ro

by capote 10y ago

> 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.

AnimalMuppet 10y ago
> 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.
- capote 10y ago
  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.
rpeden 10y ago
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.
- capote 10y ago
  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).
analogwzrd 10y ago
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.
- capote 10y ago
  > 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).

by capote 10y ago

AnimalMuppet 10y ago

> 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.

capote 10y ago
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.

rpeden 10y ago

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.

capote 10y ago
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).

analogwzrd 10y ago

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.

capote 10y ago
> 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).