13 ms·

Pretty decent article (don't agree with everything, but for the most part) > Code is secondary. Business value is first. I wish I could shout this from a moun

Pretty decent article (don't agree with everything, but for the most part) > Code is secondary. Business value is first. I wish I could shout this from a mountaintop. If there's one thing I could change about engineering culture it would be this. But then again I would lose my edge if everyone understood this, so maybe it's best that they don't Engineers: If you want to stand out in your career - take this to heart. Code is not the goal. Money is the goal, code is a tool to get the money. You work in a capitalistic business, whether you like it or not. Push your colleagues to build the thing that makes the business the most money, not the thing that is the "best" engineering solution. You will get tons of pushback on this - but eventually your pushing will bubble up to someone who works in "the business" (directors, executives, etc) and not just other engineers and they will invariably support you. This is your contrarian view now. This is your answer to Peter Thiel's question "What important truth do very few people agree with you on?". And you will thank me in 10 years.

fatneckbeard 4y ago
money is not the goal. providing a useful and valuable product or service to customers is the goal.
- xyzzy4747 4y ago
  This is incorrect. Without money you won't get salaries. And people will need to find another job (at a place that does value money).
  - croes 4y ago
    Money is just the middleman pretending to be the boss.
- AnIdiotOnTheNet 4y ago
  That's how it should be, but our society has embraced the sociopathic interpretation instead.
- ricardobeat 4y ago
  I'll have to disagree with this one, that's what that point is about. Great things can be achieved by focusing on UX and providing real value, but these are means to an end, and the business' end goal is still making money. Most of the time [1]. Can you whip up a quick & dirty feature that might generate more revenue if released tomorrow? You can bet it will be done. At this moment the engineers who know when/where to compromise stand out. [1] companies with a strong ethos or social mission do exist. If you find one that makes you happy, hold onto it :)
- rco8786 4y ago
  Totally incorrect, at least in a business context. If it were the case, you would build that useful and valuable product and then give it to your customer for free. But you would never, ever, do that (unless it was specifically as a loss leader for other products) because making money is the goal.
  - croes 4y ago
    Business context is not the whole reality, only a part of it and it's losing it's purpose.
  - dinkumthinkum 4y ago
    That’s not true because giving it away would mean you wouldn’t be able to produce the product.
- LtWorf 4y ago
  The successful startups hardly ever do that.
- zug_zug 4y ago
  There is so much packed into the phrase "the goal." - Is it the business owner's goal? Depends on the business owner. - Would the CEO have a better company if they focused on building something great rather than extracting money? Depends on the industry (the premise of capitalism is yes, but unfair markets are a thing) - Is it (betterment of society through engineering) a valid personal goal to have on a strictly moral or ethical level, with no need of evidence or efficacy? Sure, absolutely - Are people who focus on "extracting money" sheisty MBA types who lie through their teeth and exaggerate every number and kill the company in the process of trying to self-promote any random thing they can control? Sounds like a leading question... These are all worthy distinctions imo.
- sirsinsalot 4y ago
  The only reason anyone can and does make a valuable product or service is for some wealth. If not money, kudos, power, ... I don't buy the altruistic motives.
- jasondigitized 4y ago
  Only if the problem is pervasive and people are paying money for it. Providing value just increases the probability that you will make money. You can have a very valuable service/product and fail miserably because you have no idea how to run a business and lack the know how and fuel to power awareness activities like marketing and sales.
galangalalgol 4y ago
I had a boss for a while that took the opposite view. He just wanted to do interesting work. He was good at politics so he did, but the level he would have risen to in management if he had focused on business goals and money instead of fun work would have been much greater. But he also wouldn't have still been doing daily technical work which is all he wanted. We acknowledge that fun work can be part of total compensation, so accepting lower career advancement in return for more of that compensation doesn't strike me as unusual or a problem.
- rco8786 4y ago
  Yea no issues with that at all. That's why I prefaced my entire comment with "If you want to stand out in your career".
  - mfuzzey 4y ago
    I guess that depends on what you mean by "stand out" then. It is possible to stand out technically without standing out in a "how high in the org chart can you go" contest
IshKebab 4y ago
Depending on what you mean by "code" I disagree. It sounds like you're arguing for "just get it done quickly" vs "take your time and do it right". That isn't a "code vs money" debate it's short term vs long term productivity. Technical debt is a real thing. As is "decision debt" (not sure the official term; I mean where you make the wrong long-term choice because you didn't spend enough time on research / prototypes. For example: * Using Python because it lets you get something working fast. Oops three years later you're locking into Python and your app is slow as hell. You now spend all your time profiling instead of adding features. * Producing documentation and commenting code. Don't need it now. 10 years later everyone that worked on the code has left, nobody can understand it and you have to start from scratch. * Investing in tooling. * Using Bazel. It's so complicated! We'll just use Make. 5 years later a CI run uses 300 compute hours and 6 wall hours, even for fixing a typo in the docs (these numbers are not made up). Does those things produces no business value in the short term. But it definitely does in the long term. Maybe that's not what you meant.
- rco8786 4y ago
  > It sounds like you're arguing for "just get it done quickly" vs "take your time and do it right". That isn't a "code vs money" debate it's short term vs long term productivity. I'm not. I didn't say anything about speed. I am talking about deciding what to build. All of your examples lack the context of what is the best at making money for the business. You can't properly make a decision about addressing any of those things without considering the bottom line effect. Fixing performance for the sake of speed is not the right decision, unless your users are leaving because of speed and causing dollars to be lost. Technical debt is everywhere, prioritize fixing the debt that is causing monetary harm, ignore the rest of it. "build the thing that makes the business the most money" is exactly what I said. And yes there's obviously plenty of nuance to that, especially when it goes "meta" and you get into tooling and platforms and tech debt and whatnot. But as a guiding principle it is inarguably advantageous and surprisingly rarely held (in my experience).
  - dceddia 4y ago
    My mind jumps to things like.. - Don’t rewrite the architecture with microservices when the monolith is working fine - Avoid rebuilding the company blog on the latest CMS unless there are good business (time/money) reasons to do so. - Choose boring technology, which would be the ones that most of the people on the team already know, and probably not the cool new language you heard about last week. Avoid fragmenting the tech stack to keep things operationally simple. This is just a guess though – if you have some examples from your own experience it would be great to hear about some!
bob1029 4y ago
I learned this at some point while working in manufacturing. No one responsible for how much you get paid really cares how clever your idea is unless it makes the company more money. For me, the game theory gets pretty advanced at this level. My strategy now relies on enriching myself via equity and careful product decisions so that I can then go start my own software studio and do things my way. Presumably, this is what our leadership wanted all along. Trying to get my rush experimenting with new ideas under the current employer is really only shooting myself in the foot with regard to this long term plan. Any experimentation is reserved for side projects and weekends. At this point, I only bring "code" ideas to the team if I think they will legitimately improve the business in some eventual way that a non-wizard can understand.
- bitexploder 4y ago
  The irony is, I started and sold a consulting business. We got to do some things our way, but we still had to make money. Overall, I say do it, but I made choices I never imagined I would have to make. So it goes.
  - KyeRussell 4y ago
    This is really the next layer up in the ‘galaxy brain meme’ of this thread. The understanding that the people that dissuade you from gold plated engineering solutions are not some inherently different monsters. Rather, they’re doing at least roughly what you’d do in the same situation.
    - bitexploder 4y ago
      It’s the central tension we always had. Can you do enough your way, and as you grow, your teams way while still making money. Hackers have an ethos and working for big corporate behemoths often means compromising that ethos. I feel we did, and still do, a good job. You can get rid of so much red tape, focus on quality, have a really fun culture etc. and if you hire pragmatic folks who accept they get all of that in return for doing the make money part of consulting it can be a ton of fun and very rewarding. But the owners and managers in the business are always balancing it.
bradlys 4y ago
I disagree with both. Code and business value are worthless. Boss approval is literally everything. It really doesn’t matter if your ideas make a ton of business sense if they are in conflict with your direct manager or any part in the chain of hierarchy. As long as they don’t like what you’re saying - you’re literally worse than worthless. Often this is because your idea isn’t their idea - therefore damage to ego. Damage to ego means get that guy out of here and make sure I don’t hear more from them. People need to understand that you’re hired for a job. You’re a glorified and well compensated code monkey. Even at $1m/yr - still a god damn code monkey. You jump when they say jump. I’ve yet to meet any hierarchy chains that are truly open minded to a low level IC saying anything that counters them. I’ve worked at quite a few places too and talked to a lot of folks about this. You’ll thank me in ten years because you’ll become a bootlicker and actually make progress in your career rather than being stuck in senior/staff until you burnout from the industry.
- tester457 4y ago
  This is the real answer. Ego is greater than business, money, and code.
- tehjoker 4y ago
  ahh and finally we get the real answer that careerism is about playing jester to the court of the mad king regardless of any other concerns if you don't want to be a jester and you want satisfaction doing a good job professionally you need a union
- ro_sharp 4y ago
  > You jump when they say jump Thankfully sometimes 'they' are the customers paying real money for a product or service that's valuable to them. But as you say, larger organizations have more room for political distractions on the way to giving that customer what they want.
- hbrn 4y ago
  > Boss approval is literally everything. This is such a sad corporate loser mentality. Bosses are humans. They can be wrong. They can be convinced. Even manipulated, if that's your game. > you’re hired for a job. You’re a glorified and well compensated code monkey Only if you choose to treat yourself like one. I'm hired for my domain expertise that my bosses lack. I can understand 60-80% of their domain, they can understand 5% of my domain. When I'm saying that feature that they want is a nice-to-have and I don't want to build it unless I see evidence of it's value, they usually listen. > I’ve yet to meet any hierarchy chains that are truly open minded to a low level IC saying anything that counters them I worked at multiple startups (between 4 and 100 in size) and I always had a voice, even early in my career. Maybe you're the problem? > you’ll become a bootlicker and actually make progress in your career rather than being stuck in senior/staff Where exactly does the bootlicker progress? A code monkey doesn't become VP/C-level through bootlicking, there are plenty others with much better soft skills. At best you'll be a code monkey turned manager (which is worse than staff).
nunez 4y ago
Agreed. There is a ton of resume/leetcode-driven-development out there.
nunez 4y ago
Ironically, demonstrating business value is exactly how you can get justification to build your own things from scratch!
croes 4y ago
>Money is the goal, code is a tool to get the money. You work in a capitalistic business, whether you like it or not. Pu Capitalism and money are actually only the means to an end, to achieve the best possible for society. But as is so often the case, at some point the means becomes the end.
- sirsinsalot 4y ago
  As if capitalism in practice has ever been about the best outcome society wide. It's about a means of allowing wealth disparity while the have-not masses are too distracted to get out the guillotine
  - croes 4y ago
    You are still confusing the means with the end. It is not about what capitalism is about, it's about why society chose capitalism instead of other forms of economy. That's why capitalism needs laws to tame it's worst excesses.
wankle 4y ago
"What important truth do very few people agree with you on?" For me it's that Apache is the best web and proxy server, Java is the best programming language and platform, Eclipse is the best IDE and never use anything made formerly or currently by Russians including nginx and JetBrains' stuff.
- as1992 4y ago
  I mean irrespective of Apache/Java/Eclipse, saying to never use something made by someone just because it was developed by a company/people of a certain nationality is just silly.
whateveracct 4y ago
> If you want to stand out in your career - take this to heart. Code is not the goal. Money is the goal, code is a tool to get the money. You work in a capitalistic business, whether you like it or not. On the flipside, you can be like me and be "meh" about business value (or at least, not a maximalist about it) and treat code as the point and fun/art/etc (easy to do with an FP language, for example). You'll still deliver value and even squeak in some fancy code that isn't the best business value. The result? Over the years, your employer(s) effectively subsidize your code-for-fun's-sake using the money they make from business value others focus so much on :)
lr4444lr 4y ago
But if I don't build it with Rust with pure functional programming, how could I scale type correct, shared-nothing architecture? Who cares if customers like it? It could be a disaster if Coq cannot verify its correctness! ;-)
CM30 4y ago
You can probably also extrapolate this advice to most jobs that involve building or manufacturing something. The way you make it, the techniques you use, the practices you put into play... are all secondary to whether what you're building actually serves a purpose/fills a need. And that's equally true of everything from programming to design to writing. The value of a newspaper article is often the story it tells, not the actual way it was written. Same with a video, film, tv show, design, or whatever else. Most people don't care how good your technique is or how elegantly the product was made, they care about whether it does something they care about.
badpun 4y ago
This works in non-dysfunctional organizations only. In dysfunctional ones, the inmates are running the asylum and you will be scoffed at if your code doesn't follow the latest trends and buzzwords (e.g. functional programming). Nobody represents the business value - the product owner cares only about features being delivered and doesn't care (or, usually, understand) how the engineers do it, and the engineers are busy outnerding each other with "cool" tech. If you'll propose simple solutions using old and reliable tech, the team will think you're a lazy moron.
roncesvalles 4y ago
Unless you're in a <10 headcount everyone-does-everything startup, by the time work reaches software engineering it's already been determined as having good business value. It's rarely a software engineer's job to challenge that determination unless new information emerges that wasn't factored into the original decision. Also, maybe my perspective is skewed from only ever working at gigantic companies but what usually grows a career is making your manager's life easy - becoming someone who reliably gets shit done on time and without drama.
- tj-teej 4y ago
  I don't think this is the case. I think most engineering teams will have a "backlog" of tech debt. Some are things they want to do (the original implementation is icky but could be lived with for years until requirements change) and some will save the team hours per week in distractions/maintenance. Being able to evaluate the actual impact of the "tech debt clean-up" and pick the one which helps the business will absolutely set you apart from your peers.
- simon--poole 4y ago
  I think you massively underestimate the number of startups with product engineers. It's becoming a much more popular approach with many high-performing startups, even up to the 250+ headcount tiers.
- Too 4y ago
  The execution by swe can still take 10 times longer depending on if you go with a proven, quick and dirty straightforward YAGNI solution vs reinventing the wheel in latest cool fad, with hundred layers of abstractions and configurations in beautifully crafted code in the most poetic rube goldberg machine you have ever seen.
auggierose 4y ago
Everybody agrees counting lines of code is a bad idea to measure progress in programming. Now you say measuring the money it makes is the way to go. Money is not the goal. Money is just another tool. Like VSCode.
- terminal_d 4y ago
  I love this comment. It dodges the point so well.
shrimp_emoji 4y ago
>Code is not the goal. Money is the goal >eventually your pushing will bubble up to someone who works in "the business" (directors, executives, etc) and not just other engineers and they will invariably support you MBA-driven development when You can never go wrong when optimizing for profit above all else.
yobbo 4y ago
> Money is the goal, code is a tool to get the money. This is an obvious and empty statement if it's not used in specific cases. Unless you have something new to add in the "how to get money debate" the distinction between "code" and "value" is irrelevant. When I've heard this, it's typically way to trivialise engineers and shut down discussion. "I don't understand how this contributes value, therefore all your contributions are worthless."
- rco8786 4y ago
  That’s quite a conclusion to jump to
bdangubic 4y ago
This same argument permeates in lots of other facets - especially things like compensation. Most tech people I feel do not realize that their compensation is not based on their actual “worth” but their worth to the employer cutting the checks. It is all about money and nothing else. I know people that make close to 7-figure total compensation package who would fail job interview in 98% of the companies (this number is actually closer to like 99.23%)
pjmlp 4y ago
When anyone comes up with the idea of lets rewrite X, or refactor Y, that is always one of my first questions. What value does that bring to us or our customers, versus the money spent on doing that. Many devs tend to forget that features can be measured in time spent on X multiplied by hourly rate.
amorphous 4y ago
This does not apply to the typical software engineer. Rather this: > Code is secondary. People are first This is easily overlooked. Your social skills matter most. Leading, listening, communication. Most problems are people problems.

fatneckbeard 4y ago

money is not the goal. providing a useful and valuable product or service to customers is the goal.

xyzzy4747 4y ago
This is incorrect. Without money you won't get salaries. And people will need to find another job (at a place that does value money).
- croes 4y ago
  Money is just the middleman pretending to be the boss.
AnIdiotOnTheNet 4y ago
That's how it should be, but our society has embraced the sociopathic interpretation instead.
ricardobeat 4y ago
I'll have to disagree with this one, that's what that point is about. Great things can be achieved by focusing on UX and providing real value, but these are means to an end, and the business' end goal is still making money. Most of the time [1]. Can you whip up a quick & dirty feature that might generate more revenue if released tomorrow? You can bet it will be done. At this moment the engineers who know when/where to compromise stand out. [1] companies with a strong ethos or social mission do exist. If you find one that makes you happy, hold onto it :)
rco8786 4y ago
Totally incorrect, at least in a business context. If it were the case, you would build that useful and valuable product and then give it to your customer for free. But you would never, ever, do that (unless it was specifically as a loss leader for other products) because making money is the goal.
- croes 4y ago
  Business context is not the whole reality, only a part of it and it's losing it's purpose.
- dinkumthinkum 4y ago
  That’s not true because giving it away would mean you wouldn’t be able to produce the product.
LtWorf 4y ago
The successful startups hardly ever do that.
zug_zug 4y ago
There is so much packed into the phrase "the goal." - Is it the business owner's goal? Depends on the business owner. - Would the CEO have a better company if they focused on building something great rather than extracting money? Depends on the industry (the premise of capitalism is yes, but unfair markets are a thing) - Is it (betterment of society through engineering) a valid personal goal to have on a strictly moral or ethical level, with no need of evidence or efficacy? Sure, absolutely - Are people who focus on "extracting money" sheisty MBA types who lie through their teeth and exaggerate every number and kill the company in the process of trying to self-promote any random thing they can control? Sounds like a leading question... These are all worthy distinctions imo.
sirsinsalot 4y ago
The only reason anyone can and does make a valuable product or service is for some wealth. If not money, kudos, power, ... I don't buy the altruistic motives.
jasondigitized 4y ago
Only if the problem is pervasive and people are paying money for it. Providing value just increases the probability that you will make money. You can have a very valuable service/product and fail miserably because you have no idea how to run a business and lack the know how and fuel to power awareness activities like marketing and sales.

galangalalgol 4y ago

I had a boss for a while that took the opposite view. He just wanted to do interesting work. He was good at politics so he did, but the level he would have risen to in management if he had focused on business goals and money instead of fun work would have been much greater. But he also wouldn't have still been doing daily technical work which is all he wanted. We acknowledge that fun work can be part of total compensation, so accepting lower career advancement in return for more of that compensation doesn't strike me as unusual or a problem.

rco8786 4y ago
Yea no issues with that at all. That's why I prefaced my entire comment with "If you want to stand out in your career".
- mfuzzey 4y ago
  I guess that depends on what you mean by "stand out" then. It is possible to stand out technically without standing out in a "how high in the org chart can you go" contest

IshKebab 4y ago

Depending on what you mean by "code" I disagree. It sounds like you're arguing for "just get it done quickly" vs "take your time and do it right". That isn't a "code vs money" debate it's short term vs long term productivity. Technical debt is a real thing. As is "decision debt" (not sure the official term; I mean where you make the wrong long-term choice because you didn't spend enough time on research / prototypes. For example: * Using Python because it lets you get something working fast. Oops three years later you're locking into Python and your app is slow as hell. You now spend all your time profiling instead of adding features. * Producing documentation and commenting code. Don't need it now. 10 years later everyone that worked on the code has left, nobody can understand it and you have to start from scratch. * Investing in tooling. * Using Bazel. It's so complicated! We'll just use Make. 5 years later a CI run uses 300 compute hours and 6 wall hours, even for fixing a typo in the docs (these numbers are not made up). Does those things produces no business value in the short term. But it definitely does in the long term. Maybe that's not what you meant.

rco8786 4y ago
> It sounds like you're arguing for "just get it done quickly" vs "take your time and do it right". That isn't a "code vs money" debate it's short term vs long term productivity. I'm not. I didn't say anything about speed. I am talking about deciding what to build. All of your examples lack the context of what is the best at making money for the business. You can't properly make a decision about addressing any of those things without considering the bottom line effect. Fixing performance for the sake of speed is not the right decision, unless your users are leaving because of speed and causing dollars to be lost. Technical debt is everywhere, prioritize fixing the debt that is causing monetary harm, ignore the rest of it. "build the thing that makes the business the most money" is exactly what I said. And yes there's obviously plenty of nuance to that, especially when it goes "meta" and you get into tooling and platforms and tech debt and whatnot. But as a guiding principle it is inarguably advantageous and surprisingly rarely held (in my experience).
- dceddia 4y ago
  My mind jumps to things like.. - Don’t rewrite the architecture with microservices when the monolith is working fine - Avoid rebuilding the company blog on the latest CMS unless there are good business (time/money) reasons to do so. - Choose boring technology, which would be the ones that most of the people on the team already know, and probably not the cool new language you heard about last week. Avoid fragmenting the tech stack to keep things operationally simple. This is just a guess though – if you have some examples from your own experience it would be great to hear about some!

bob1029 4y ago

I learned this at some point while working in manufacturing. No one responsible for how much you get paid really cares how clever your idea is unless it makes the company more money. For me, the game theory gets pretty advanced at this level. My strategy now relies on enriching myself via equity and careful product decisions so that I can then go start my own software studio and do things my way. Presumably, this is what our leadership wanted all along. Trying to get my rush experimenting with new ideas under the current employer is really only shooting myself in the foot with regard to this long term plan. Any experimentation is reserved for side projects and weekends. At this point, I only bring "code" ideas to the team if I think they will legitimately improve the business in some eventual way that a non-wizard can understand.

bitexploder 4y ago
The irony is, I started and sold a consulting business. We got to do some things our way, but we still had to make money. Overall, I say do it, but I made choices I never imagined I would have to make. So it goes.
- KyeRussell 4y ago
  This is really the next layer up in the ‘galaxy brain meme’ of this thread. The understanding that the people that dissuade you from gold plated engineering solutions are not some inherently different monsters. Rather, they’re doing at least roughly what you’d do in the same situation.
  - bitexploder 4y ago
    It’s the central tension we always had. Can you do enough your way, and as you grow, your teams way while still making money. Hackers have an ethos and working for big corporate behemoths often means compromising that ethos. I feel we did, and still do, a good job. You can get rid of so much red tape, focus on quality, have a really fun culture etc. and if you hire pragmatic folks who accept they get all of that in return for doing the make money part of consulting it can be a ton of fun and very rewarding. But the owners and managers in the business are always balancing it.

bradlys 4y ago

I disagree with both. Code and business value are worthless. Boss approval is literally everything. It really doesn’t matter if your ideas make a ton of business sense if they are in conflict with your direct manager or any part in the chain of hierarchy. As long as they don’t like what you’re saying - you’re literally worse than worthless. Often this is because your idea isn’t their idea - therefore damage to ego. Damage to ego means get that guy out of here and make sure I don’t hear more from them. People need to understand that you’re hired for a job. You’re a glorified and well compensated code monkey. Even at $1m/yr - still a god damn code monkey. You jump when they say jump. I’ve yet to meet any hierarchy chains that are truly open minded to a low level IC saying anything that counters them. I’ve worked at quite a few places too and talked to a lot of folks about this. You’ll thank me in ten years because you’ll become a bootlicker and actually make progress in your career rather than being stuck in senior/staff until you burnout from the industry.

tester457 4y ago
This is the real answer. Ego is greater than business, money, and code.
tehjoker 4y ago
ahh and finally we get the real answer that careerism is about playing jester to the court of the mad king regardless of any other concerns if you don't want to be a jester and you want satisfaction doing a good job professionally you need a union
ro_sharp 4y ago
> You jump when they say jump Thankfully sometimes 'they' are the customers paying real money for a product or service that's valuable to them. But as you say, larger organizations have more room for political distractions on the way to giving that customer what they want.
hbrn 4y ago
> Boss approval is literally everything. This is such a sad corporate loser mentality. Bosses are humans. They can be wrong. They can be convinced. Even manipulated, if that's your game. > you’re hired for a job. You’re a glorified and well compensated code monkey Only if you choose to treat yourself like one. I'm hired for my domain expertise that my bosses lack. I can understand 60-80% of their domain, they can understand 5% of my domain. When I'm saying that feature that they want is a nice-to-have and I don't want to build it unless I see evidence of it's value, they usually listen. > I’ve yet to meet any hierarchy chains that are truly open minded to a low level IC saying anything that counters them I worked at multiple startups (between 4 and 100 in size) and I always had a voice, even early in my career. Maybe you're the problem? > you’ll become a bootlicker and actually make progress in your career rather than being stuck in senior/staff Where exactly does the bootlicker progress? A code monkey doesn't become VP/C-level through bootlicking, there are plenty others with much better soft skills. At best you'll be a code monkey turned manager (which is worse than staff).

nunez 4y ago

Agreed. There is a ton of resume/leetcode-driven-development out there.

nunez 4y ago

Ironically, demonstrating business value is exactly how you can get justification to build your own things from scratch!

croes 4y ago

>Money is the goal, code is a tool to get the money. You work in a capitalistic business, whether you like it or not. Pu Capitalism and money are actually only the means to an end, to achieve the best possible for society. But as is so often the case, at some point the means becomes the end.

sirsinsalot 4y ago
As if capitalism in practice has ever been about the best outcome society wide. It's about a means of allowing wealth disparity while the have-not masses are too distracted to get out the guillotine
- croes 4y ago
  You are still confusing the means with the end. It is not about what capitalism is about, it's about why society chose capitalism instead of other forms of economy. That's why capitalism needs laws to tame it's worst excesses.

wankle 4y ago

"What important truth do very few people agree with you on?" For me it's that Apache is the best web and proxy server, Java is the best programming language and platform, Eclipse is the best IDE and never use anything made formerly or currently by Russians including nginx and JetBrains' stuff.

as1992 4y ago
I mean irrespective of Apache/Java/Eclipse, saying to never use something made by someone just because it was developed by a company/people of a certain nationality is just silly.

whateveracct 4y ago

> If you want to stand out in your career - take this to heart. Code is not the goal. Money is the goal, code is a tool to get the money. You work in a capitalistic business, whether you like it or not. On the flipside, you can be like me and be "meh" about business value (or at least, not a maximalist about it) and treat code as the point and fun/art/etc (easy to do with an FP language, for example). You'll still deliver value and even squeak in some fancy code that isn't the best business value. The result? Over the years, your employer(s) effectively subsidize your code-for-fun's-sake using the money they make from business value others focus so much on :)

lr4444lr 4y ago

But if I don't build it with Rust with pure functional programming, how could I scale type correct, shared-nothing architecture? Who cares if customers like it? It could be a disaster if Coq cannot verify its correctness! ;-)

CM30 4y ago

You can probably also extrapolate this advice to most jobs that involve building or manufacturing something. The way you make it, the techniques you use, the practices you put into play... are all secondary to whether what you're building actually serves a purpose/fills a need. And that's equally true of everything from programming to design to writing. The value of a newspaper article is often the story it tells, not the actual way it was written. Same with a video, film, tv show, design, or whatever else. Most people don't care how good your technique is or how elegantly the product was made, they care about whether it does something they care about.

badpun 4y ago

This works in non-dysfunctional organizations only. In dysfunctional ones, the inmates are running the asylum and you will be scoffed at if your code doesn't follow the latest trends and buzzwords (e.g. functional programming). Nobody represents the business value - the product owner cares only about features being delivered and doesn't care (or, usually, understand) how the engineers do it, and the engineers are busy outnerding each other with "cool" tech. If you'll propose simple solutions using old and reliable tech, the team will think you're a lazy moron.

roncesvalles 4y ago

Unless you're in a <10 headcount everyone-does-everything startup, by the time work reaches software engineering it's already been determined as having good business value. It's rarely a software engineer's job to challenge that determination unless new information emerges that wasn't factored into the original decision. Also, maybe my perspective is skewed from only ever working at gigantic companies but what usually grows a career is making your manager's life easy - becoming someone who reliably gets shit done on time and without drama.

tj-teej 4y ago
I don't think this is the case. I think most engineering teams will have a "backlog" of tech debt. Some are things they want to do (the original implementation is icky but could be lived with for years until requirements change) and some will save the team hours per week in distractions/maintenance. Being able to evaluate the actual impact of the "tech debt clean-up" and pick the one which helps the business will absolutely set you apart from your peers.
simon--poole 4y ago
I think you massively underestimate the number of startups with product engineers. It's becoming a much more popular approach with many high-performing startups, even up to the 250+ headcount tiers.
Too 4y ago
The execution by swe can still take 10 times longer depending on if you go with a proven, quick and dirty straightforward YAGNI solution vs reinventing the wheel in latest cool fad, with hundred layers of abstractions and configurations in beautifully crafted code in the most poetic rube goldberg machine you have ever seen.

auggierose 4y ago

Everybody agrees counting lines of code is a bad idea to measure progress in programming. Now you say measuring the money it makes is the way to go. Money is not the goal. Money is just another tool. Like VSCode.

terminal_d 4y ago
I love this comment. It dodges the point so well.

shrimp_emoji 4y ago

>Code is not the goal. Money is the goal >eventually your pushing will bubble up to someone who works in "the business" (directors, executives, etc) and not just other engineers and they will invariably support you MBA-driven development when You can never go wrong when optimizing for profit above all else.

yobbo 4y ago

> Money is the goal, code is a tool to get the money. This is an obvious and empty statement if it's not used in specific cases. Unless you have something new to add in the "how to get money debate" the distinction between "code" and "value" is irrelevant. When I've heard this, it's typically way to trivialise engineers and shut down discussion. "I don't understand how this contributes value, therefore all your contributions are worthless."

rco8786 4y ago
That’s quite a conclusion to jump to

bdangubic 4y ago

This same argument permeates in lots of other facets - especially things like compensation. Most tech people I feel do not realize that their compensation is not based on their actual “worth” but their worth to the employer cutting the checks. It is all about money and nothing else. I know people that make close to 7-figure total compensation package who would fail job interview in 98% of the companies (this number is actually closer to like 99.23%)

pjmlp 4y ago

When anyone comes up with the idea of lets rewrite X, or refactor Y, that is always one of my first questions. What value does that bring to us or our customers, versus the money spent on doing that. Many devs tend to forget that features can be measured in time spent on X multiplied by hourly rate.

amorphous 4y ago

This does not apply to the typical software engineer. Rather this: > Code is secondary. People are first This is easily overlooked. Your social skills matter most. Leading, listening, communication. Most problems are people problems.