4 ms·

If you've been working as a developer for more than a few months you really should have delivered some form of business value. Building a proof-of-concept that

by jonfw 5y ago

If you've been working as a developer for more than a few months you really should have delivered some form of business value. Building a proof-of-concept that allows a company to explore an idea before being thrown in the bin is still business value. This sort of question is mostly asked to understand if you know/care how your work impacts the bottom line.

loup-vaillant 5y ago
My point is, whether you can know how your work impacts the bottom line is often outside your control. Especially at larger companies, where most people work on tiny pieces. For my part, I worked on many things, and have no idea how it impacted the bottom line most of the time. I mean, I believe I had a positive impact most of the time, but don't ask me about the magnitude of that impact. I'm a programmer, not an accountant. Besides, I do care about having a positive impact. It's just that most of my criteria are not directly measurable in $$$. Its' more about user happiness, maintainability, reliability… and some of those priorities may even be at odds with the bottom line (lack of quality is often an externality[1]). [1]: https://www.youtube.com/watch?v=k8gIJOy0c2g&t=152s https://www.youtube.com/watch?v=k8gIJOy0c2g&t=152s
- TheOtherHobbes 5y ago
  It shouldn't be "Delivered business value and here's exactly how much to the cent." It's more "Did something a manager considered useful." Of course you get people who can invent or re-engineer processes that add huge amounts of book value, but they're rare. Generally if you find someone more competent than average who also has business awareness, the business value will take care of itself. Especially if they're well managed. Conversely you want to avoid devs with absolutely no business awareness at all. They'll spend all their time tinkering with the new hotness for the sake of it, and usefulness will not ensue.
- ebiester 5y ago
  The counter to that is the allegory of the bricklayers. " A traveler came upon three men working. He asked the first man what he was doing and the man said he was laying bricks. He asked the second man the same question and he said he was putting up a wall. When he got to the third man and asked him what he was doing he said he was building a cathedral." I get that you're not an accountant. However, I want to know that you understand the impact of your work. Someone who understands the larger picture will be able to cogently argue why this technical debt or bug is more important than that technical debt or bug. It's also the job of product to understand it, but the best product teams I've been a part of have multiple team members who understand the business impact. Sometimes, you'll be lucky and say that your feature contributed a million dollars to the bottom line. That's luck to some extent. However, I'm more interested that you understand the business context outside your individual work.
TigeriusKirk 5y ago
One guy I worked with had been a developer for 15 years and the project we were on together was the first one that had actually shipped in his entire career. The industry is a complicated place with massive resources wasted on projects that go nowhere.

by jonfw 5y ago

loup-vaillant 5y ago

My point is, whether you can know how your work impacts the bottom line is often outside your control. Especially at larger companies, where most people work on tiny pieces. For my part, I worked on many things, and have no idea how it impacted the bottom line most of the time. I mean, I believe I had a positive impact most of the time, but don't ask me about the magnitude of that impact. I'm a programmer, not an accountant. Besides, I do care about having a positive impact. It's just that most of my criteria are not directly measurable in $$$. Its' more about user happiness, maintainability, reliability… and some of those priorities may even be at odds with the bottom line (lack of quality is often an externality[1]). [1]: https://www.youtube.com/watch?v=k8gIJOy0c2g&t=152s https://www.youtube.com/watch?v=k8gIJOy0c2g&t=152s

TheOtherHobbes 5y ago
It shouldn't be "Delivered business value and here's exactly how much to the cent." It's more "Did something a manager considered useful." Of course you get people who can invent or re-engineer processes that add huge amounts of book value, but they're rare. Generally if you find someone more competent than average who also has business awareness, the business value will take care of itself. Especially if they're well managed. Conversely you want to avoid devs with absolutely no business awareness at all. They'll spend all their time tinkering with the new hotness for the sake of it, and usefulness will not ensue.
ebiester 5y ago
The counter to that is the allegory of the bricklayers. " A traveler came upon three men working. He asked the first man what he was doing and the man said he was laying bricks. He asked the second man the same question and he said he was putting up a wall. When he got to the third man and asked him what he was doing he said he was building a cathedral." I get that you're not an accountant. However, I want to know that you understand the impact of your work. Someone who understands the larger picture will be able to cogently argue why this technical debt or bug is more important than that technical debt or bug. It's also the job of product to understand it, but the best product teams I've been a part of have multiple team members who understand the business impact. Sometimes, you'll be lucky and say that your feature contributed a million dollars to the bottom line. That's luck to some extent. However, I'm more interested that you understand the business context outside your individual work.

TigeriusKirk 5y ago

One guy I worked with had been a developer for 15 years and the project we were on together was the first one that had actually shipped in his entire career. The industry is a complicated place with massive resources wasted on projects that go nowhere.