13 ms·

Nobody ever paid me for code

210 points by BiteCode_dev 3y ago

soumid 3y ago
[flagged]
- BiteCode_dev 3y ago
  It seems you haven't read the article.
mcqueenjordan 3y ago
Also known as the “jobs to be done” pattern.
zelphirkalt 3y ago
I disagree with some of the things the article describes. Not that they aren't real or that the world works differently, but with those things themselves. For example: (1) It should always be ones goal to improve ones technical skills, not only in the beginning of ones career. Too often have I seen bad code or lack of knowledge about computer programming concepts, that people ought to know, considering the time they spent in their career. Those things will result in "solutions" but those solutions might not be the most maintainable and understandable. Fine if you switch jobs every 2 years and never have to deal with the aftermath, but not fine for people, who value quality. All your communication skills won't make up for a brittle base due to insufficient technical skills. (2) To let others dictate, how you develop professionally, being the ultimate yes-sayer. Improve the way you yourself value and see as important and stick to your guns. Not everyone needs to go along career paths that some company with mediocre management has laid out for them. Not everyone needs to become a talker. (3) Perhaps the title is a bit too extreme. Code can be the solution. Good code even more so. Personally that's what I want to do. Write code to solve problems. Of course, only write it, when it is necessary. Who wants to write code only to have it be discarded, because it was not needed in the first place. (OK maybe sometimes one does, for the learning experience.)
- FrustratedMonky 3y ago
  Yeah. The article has the right idea in general. But, It's pretty thin, there are entire books written on this subject that dig into the 'nuance'. I've also had consultants get a bit to 'hand-wavy' like described, and then I don't trust they can code either.
  - acedTrex 3y ago
    I feel like the hand wave should be the default until actually asked then you can dive into specifics.
- chadash 3y ago
  > Code can be the solution. Good code even more so. I think I agree with the author here. Code is a tool. This is like saying "a wrench can be the solution and a good wrench is even more valuable". I'm sure that car mechanics have very strong opinions about various wrenches. But I'm paying to get my car fixed. Sure, it's nice to hear that your shop has the latest equipment, but at the end of the day, the thing that matters most is that you can fix my car. Even as a developer, I hardly care about the code quality or what language you use if you provide a good and reliable service. I've never thought to myself, geez, I love AWS, but I really wish they'd move away from Java.
  - kraftman 3y ago
    You would if their services crashed every day though right? Like when you pay to get your car fixed, there's an implicit expectation that it will be fixed well enough that it doesnt break the same way again for a certain amount of time, and it doesnt make anything else break. If you found out that the garage was using wooden wrenches that broke 10% of the time and they passed that cost onto you, or occasionally broke and damaged the car, but didn't in your case, you wouldnt be like 'oh well, they fixed the problem, Ill keep going back to them'.
    - chadash 3y ago
      i'm trying to think of the coding equivalent of wooden wrenches? Let's say that's an app written entirely with VBA. If I perceive that it solves my problems, then for most use cases, i'd be fine with it. I guess if it's running my bank account or it's a platform for deploying my code, maybe i'd care somewhat, but in 99% of cases, i wouldn't. But the reality is that most code is written in a language that's good enough. It's a metal wrench that might be showing some rust. Do I think that PHP is a good language to start a project with today? Of course not. Do I care if you wrote your site 15 years ago and it still runs on PHP? Not really.
Greenpants 3y ago
This is indeed a good point to keep in mind. I do tend to forget sometimes. As a perfectionist I'm always planning code refactors in my mind, but rarely do they see the light of day; they're often minimal and don't add anything to the solution. There's very little added value. Know your audience – know what they need, and you can develop accordingly.
srazzaque 3y ago
Good read, a lot that resonated with me. My comms (written and verbal) to stakeholders are something I'd rate as "OK". But, on occasion I still do catch myself out diving into tech talk at the wrong times. I'd add that with a certain level of seniority, for those developers that enjoy working directly with clients and stakeholders, it's expected that you can translate in both directions. That is: not just going from "tech to non-tech", but also shaping a "non-tech" requirement into an actual solution. Clients will rarely ask for redundancy, persistence or ACID compliance. But they will say things like "I want some sort of completeness check, and I can't have the system drop any messages from the exchange."
wheelerof4te 3y ago
The clients pay me to create quality products or services. The "quality" is key. I can stop the leak, but if I did it badly, the sink will start leaking again. And it will leak worse.
jdsullivan 3y ago
The more important and general wisdom: know your audience. You will sometimes have clients with deep technical backgrounds that expect a sufficient level of detail to have any faith or trust in your solutions. You need to be able to tailor your communication based on the situation and the expectations of the audience in question. This is never binary and can be especially challenging when you need to communicate to multiple people at the same time that each require different levels of detail.
- deleted 3y ago
  [deleted]
- AmIDev 3y ago
  This is something I struggle with. I have a weekly meeting which includes TL, Manager, PM and sometimes Staff engineers, Data analysts, Managers of downstream teams etc. I try to keep the details to the lowest denominator, which usually means mentioning what the problem is and what the proposed solution is in few lines. But eventually someone will ask for more details, and then the conversation veers off to technical discussion that I am sure the PMs and Analysts don't understand.
  - kupopuffs 3y ago
    tech design meetings shouldn't have product. and if this is a demo, then it should only really require stakeholders. if the meeting is for product to share their vision or requirements, save the tech talk for later its very tempting to get into the weeds of things, but this can be "parking lotted" as the kids say
- BiteCode_dev 3y ago
  Indeed, but this general wisdom is too vague to be useful on its own. When I was young, I heard it many times, and couldn't make anything from it. What's the audience exactly? How do I know them? Once I know them, what am I suppose to do? And all that stuff is contextual, so what are we talking about really? When learning to negociate, knowing your audience is a very different thing than when trying to teach. Very few people are able to pull it off accross fields. So I decided to write an article that targets a specific case with a concrete application and examples. This would have been more useful to me back then.
xen0 3y ago
Sometimes I know what I want, and if a salesman starts trying to sell me a 'concept' or a 'lifestyle' instead of a car, I'm walking away.
- stavros 3y ago
  If you're at the lot, you've already been sold on the concept and the lifestyle, and you're there to buy. Amazon doesn't try to tell you how great sweaters are when you're on the checkout page of buying one.
  - justinclift 3y ago
    > If you're at the lot ... That misses a whole bunch of reasons a person could be "at the lot" other than for buying. Easy, real world examples: * You're killing time while waiting for the other half at a nearby store * There's a whole group of vehicle "lots" next to each other, so you're taking a look at all of them for a better understanding of your options * Your car is being repaired / in for a service (or similar) (etc)
    - stavros 3y ago
      > * You're killing time while waiting for the other half at a nearby store I wouldn't kill time at a fertilizer store if I didn't have a garden, though. > * There's a whole group of vehicle "lots" next to each other, so you're taking a look at all of them for a better understanding of your options This still means that I realize the value of a car for me. > * Your car is being repaired / in for a service (or similar) Same as the one above here. Selling you on the concept/lifestyle is for when you don't yet know you need a specific thing. When you're at the lot, you're past that.
      - Miraltar 3y ago
        Lifestyle and concepts in this context can be more specific. This particular car would be perfect for your daily routine because of this, this and this... Oh but this one allows you to take your children on holidays conveniently beacause of that... Yes you already have/want a car but you might still be convinced to buy a car you didn't plan.
Artgor 3y ago
In general I agree. But if this approach is applied for the same system many times in a row, it can cause technical debt.
bluedino 3y ago
This works the other way around. You'll get a technical project manager, and they'll bring in a consultant to do some programming. "All you guys need to do is write a little code to interface X with Y, it should only take you a couple days" They don't think, "you'll need to get with this vendor, use this outdated software, follow these restrictions, make sure the UI matches up with the other program, interface with this authentication library..." That's all part of "Add UPS shipping support to our CRM software"
- quickthrower2 3y ago
  Just a checkbox. Why are you still working on it after a week!
  - vxNsr 3y ago
    At that point you give them the checkbox. “Here it is, you’re right it was sooo easy, oh you wanted it to do something… yea that’s why it takes longer”
  - ooterness 3y ago
    It's all blocked because Galactus still doesn't support ISO timestamps. https://youtu.be/y8OnoxKotPQ https://youtu.be/y8OnoxKotPQ
    - kirubakaran 3y ago
      Common mistake. It's Omega Star that doesn't support ISO timestamps even though they said they would, and Galactus (which supports ISO timestamps) is getting deprecated by the end of the month.
      - quickthrower2 3y ago
        It is Omega Star that doesn't support ISO timestamps, correct, but it is EKS (Entropy [K]haos Service?) that getting deprecated at the end of the month. Without that you can't provide a time stamp for the end of the universe to Galactus. Having said that, I am probably wrong too.
quickthrower2 3y ago
Yet every interview I have been to has had several coding tests, take homes and technical interviews. Your code is reviewed, and someone decides after 6 months if you are up to task. As an employee you can’t find an external solution and resell it with some smooth talking for double the price and go play golf. Rather you will be subjected to agile practices and if unlucky logging your hours against tickets. Most coders are actually paid to code. (trying to do non coding work beneficial to the business is actually a struggle unless it is in your assigned role!)
- swalsh 3y ago
  People don't pay for welding, they pay for buildings, cars etc... but they also are going to be real disappointed if the welds fail.
  - BSEdlMMldESB 3y ago
    welding needs to be repeated for every building code is written once, then everybody can copy it to make use of it why is this such a huge problem? what to do about it? I have a lot of opinions around this but it doesn't matter
    - pdimitar 3y ago
      Code is written once? Can't be farther from the truth. Code has to be iterated on, quite often too.
      - BSEdlMMldESB 3y ago
        to write is different from to rewrite but c'mon. I'm referring to the fact that code can be made into libraries, or APIs if you're so keen on collecting rent and then as a digital asset, the library can be copied and distributed, hence code can be written once (one team writes it) then everybody else can use it with no additional cost, (again, unless you actually want to tax/collect-rent from other people, then you make up this additional cost)
smallstepforman 3y ago
Using the analogy of a car, I’m not buying ANY car but a SPECIFIC car with features and quality that meet my requirements. My client is not getting ANY code, but featured and performant code. My client is fed up with basic code, they want “quality” and are paying appropriately for it. So yes, there are clients that pay for “quality” code because they do want more than just a solution.
- duncan-donuts 3y ago
  Nah I think the OP post still works here. You might have requirements of a car that only some niche manufacturer can meet because you have a very specific problem to solve. Let’s say you’re in a wheelchair and you need a vehicle that is accessible for you. Your solution you’re paying for is more specific than others.
  - jacobr1 3y ago
    And similarly, nobody is paying for the blueprints, or CAD files, or assembly or whatever, they just want the car. There might be people that DO want those intermediate outputs (other car builders, hobbyists) but not the usual car-buyer, even one with very-specific needs. The one exception to this might be, the car-buyer that does intend to heavily modify their vehicle, might value to the availability its creative inputs so that modification later on is easier.
- zepolen 3y ago
  Exactly. One plumber will fix the leak with a new gasket. The other will fix the leak with duct tape. Both will solve the customers immediate need and stop the leak.
yobbo 3y ago
> They told their customers: "1000 Songs in Your Pocket". That is talking about specs, and it is exactly what the competition did too. Here in the unit "number of songs". Maybe most people at the time couldn't translate GBs into number of songs, but nowadays bandwidth or "surf" is talked about in terms of GBs because it has become familiar through experience. The iPod had better specs and better design. The original Jobs presentation even puts up a table or 2x2 illustrating how the iPod specs would be superior. Obviously, one adapts language to audience, but I've never seen a case where this is the real reason for success or failure.
- scarface_74 3y ago
  > The iPod had better specs and better design. It in fact had less space than the Nomad and was kind of lame On top of that, it didn’t have wireless! /s.
  - rvbissell 3y ago
    > It in fact had less space than the Nomad and was kind of lame Rob Malda, is that you?
  - stonemetal12 3y ago
    But would a Nomad it in your pocket? I have never seen a Nomad IRL, the pictures on wikipedia make it look like the size of a CD player, not something that would fit in my pocket.
    - scarface_74 3y ago
      I can’t blame you for not getting the reference. It is over 20 years old now. https://m.slashdot.org/story/21026 https://m.slashdot.org/story/21026
    - 1-more 3y ago
      Yeah the key differentiator was that the other hard disk MP3 players up to that point used 2.5" laptop harddrives and removable AA batteries and fit in a cargo pocket. The iPod used a 1.8" harddrive and a slim built-in rechargeable battery and fit in a jeans pocket (it was pretty huge for a shirt pocket but could fit in there if you didn't care about it ruining your lines). The term "laptop harddrives" of course confuses the issue: the Macbook Air first shipped with a 1.8" harddrive before it changed to flash storage.
ghoshbishakh 3y ago
A typo: "well enought" -> "well enough"
- Jarmsy 3y ago
  The whole article is clearly written by someone struggling with English, with no checking or editing. They use 'seldom' in a way that makes no sense, where I guess they meant 'hardly'. Then there's 'hilight' instead of highlight. That's just in the first few lines.
RcouF1uZ4gsC 3y ago
I think this is wrong: You are getting paid to code. The person's problem is not code, but if code is the solution, that is what you are getting paid for. The plumber is getting paid to change a gasket. If you look at the invoice, it won't say "water management" but it will include the gasket and labor. Same for the car. If you look at the invoice, if won't say "personal transportation, instead you will see the car and the options that you paid for. Same if you go to the doctor. It will list the various procedures and diagnosis and bill for those. This conflates two issues: deciding the solution to your problem, and paying for the solution. Marketing and sales is about convincing people that what you are selling is the solution to their problem. For example, car ads try to convince you that the specific car is the solution to going places in comfort with status. A beer ad tries to convince you that this particular beer is the solution for you having a great time with friends. You actually then pay for the concrete car or beer, etc.
alexghr 3y ago
> So keep the technical talk to your peers, unless the client explicitly asks for it. This! Adapt the message to the target audience. The code we write is an abstraction, it takes some input and produces an output. For many it's a black box or can be thought of as a black box. Start high and go lower and lower until you reach the right level of detail for the person you're communicating with.
- swayvil 3y ago
  Sometimes the client wants to talk about code. He wants to be involved in the technical decisions. But he doesn't know diddly about code. So you have these frustrating conversations and try not to call the client an idiot.
dataviz1000 3y ago
A power plant stopped working. None of the engineers could fix it. They called the retired engineer who designed the power plant years ago for help. He arrives, looks at the control room panels, walks through the plant, pulls out a screw driver, and turns a screw. The power plant starts working again. He quickly writes an invoice for $100,010. The manager complains asking why he is charging so much when he only turned one screw. The engineer replies, "I'm charging $10 for turning the screw and $100,000 for knowing which screw to turn."
- eesmith 3y ago
  That story was old even before my parents were born. https://quoteinvestigator.com/2017/03/06/tap/ https://quoteinvestigator.com/2017/03/06/tap/ and https://www.snopes.com/fact-check/know-where-man/ https://www.snopes.com/fact-check/know-where-man/ . Instead of making up a new variant, you might use one with a bit more historical lineage. My favorite version involves Charles Proteus Steinmetz, the deservedly named "Wizard of Schenectady", from this 1965 letter to the editor at Life: https://books.google.co.uk/books?id=QFMEAAAAMBAJ&lpg=PA16&pg=PA27&redir_esc=y&hl=en#v=onepage&q&f=true https://books.google.co.uk/books?id=QFMEAAAAMBAJ&lpg=PA16&pg... taking place supposedly around 1920 (see https://history.stackexchange.com/questions/43438/in-what-year-did-charles-proteus-steinmetz-fix-fords-generator-for-the-famed-1 https://history.stackexchange.com/questions/43438/in-what-ye... ). That still doesn't mean it actually happened, but you might get an up-vote by Steinmetz fans. ;)
- lispisok 3y ago
  Great Facebook boomer copypasta but my takeaway from this story is the power plant was designed very poorly if one loose screw can take down the whole system and is not diagnosable by anybody who didnt design the system. The retired engineer did a very bad job.
jroseattle 3y ago
I was around for the mp3 "revolution", so I'll add to the author's discussion point about the ipod. The thousand-songs-in-your-pocket sales pitch was more than lifestyle/concept -- it was an actual feature. All of the other players at the time were big & bulky because the components they used for storage & battery required the corresponding form factor. The "pocket" part of the sales pitch was exactly that: the ipod physically fit in your pocket because the components were smaller and more integrated. In the stage demoes by Jobs, he shoves the ipod into his jeans. To the author's point about "you pay for the problem it solves, or the needs/wants it fulfills", the implied need here was that you need this to be small and out-of-the-way -- not a miniature home-stereo attached to your belt. And not to pick on the author, but I don't find the ipod reference very applicable to the case of communicating with your consulting clients. Sure, you have to speak to your audience -- but direct 1:1 contact with a handful of stakeholders is hella different from millions of consumers who never asked you for a specific set of features and a timeline.
- plorkyeran 3y ago
  It wasn’t just that it physically fit in your pocket - it also worked in your pocket. I had pants at the time which I could fit a portable CD player in, but walking around without the music skipping required carefully holding it steady. The earlier non-flash mp3 players tended to have HDDs that similarly weren’t great with motion while in use.
- throwaway3655 3y ago
  The reality distortion field is strong. An mp3 player was in every kid's jeans pocket before the ipod was even announced.[0] Its innovation was costing twice as much and having white earphones, which made it suitable as a wealth-signaling fashion accessory. [0] https://en.wikipedia.org/wiki/Portable_media_player#The_MP3_standard https://en.wikipedia.org/wiki/Portable_media_player#The_MP3_...
  - jroseattle 3y ago
    True, except for the every-kid part. The market was pretty fragmented back then. Nonetheless, I was referring to the sales pitch. And Jobs never let facts get in the way of a good story. :-)
gorpomon 3y ago
Overall I like posts like these, as they are a reminder that you're not really paid for agonizing over eloquent or great code, but just code that "gets the job done". But then if you over-index on this viewpoint, you'll end up needing posts which remind you that this is a craft and that code needs some agonizing over. What I've been pondering lately is another way to sum this up that is more future focused: Let's say a genie walks into your project and says that you can have 1.5 times the features you have right now, for 3x the code. The genie promises that the code will be "alright, maybe just kind of a bit bad". I think around 2/3 of developers would say no, but I suspect 2/3 of people in product management, sales, marketing, etc would say yes. Everyone would be sympathetic to the problems this would create, but the allure of getting 1.5X ahead on your roadmap is probably too hard to ignore for those other disciplines. It's basically accelerating all your other work streams by 1.5, at the expense of potentially bogging down dev. Obviously, countless caveats exist, but it does in general feel right, and feels like it hints at the fundamental causes of tension between business and development.
- wbl 3y ago
  How much does it bog down? If for the next two years you're adding features at half the rate but you got a five year boost you're still head and some of that work can simplify the situation.
  - gorpomon 3y ago
    Yeah that's the thing, it's hard to say how much you are bogged down. As time goes on the value of the 1.5x multiplier increases in value, but then you also run the risk of massive spaghetti code (more or less, depends on what the genie considers good). I don't know if there's great value in trying to figure out if you would quantitatively get ahead though. I think the value is in just realizing that some groups are inclined to perhaps take that risk, and some groups are not.
  - josephg 3y ago
    If your code has increased by 3x, that means 2/3 of the entire project is unknown to your developers. It’ll take a lot of work to just get everyone across that much extra code. To say nothing of how much work it would be to tame it. I agree with the GP. Business people would probably salivate over this, but if it were up to me I’d want to say no.
jmpeax 3y ago
> If your sink is leaking, you might call a plumber to fix it. > But you don't really pay the plumber for putting a new gasket in. > In fact, you don't care about the gasket, you care about not having you sink leaking. I care about the gasket. If I want the sink to not leak then one way is to not use the tap/faucet. There are countless ways to fix the problem of your sink leaking, but only very few that you really want. Knowing your problem is important so that you don't waste time and money on charlatans. I care about the damned gasket.
- polishdude20 3y ago
  Yeah, you may not KNOW you care about the gasket, you may not even know what a gasket is or where it is, but you care about it because you care about the outcome it gives you.
- blitz_skull 3y ago
  No you don’t. You think you do, but you really don’t. You care about the problem going away. Sure maybe YOU care about the gasket, but there’s some other technical domain in your life that can sub in and the metaphor stands. No one is technical enough in every arena of life to care about the gasket. Also to really stretch this metaphor to its limit, it’s exactly as the author said—there ARE countless ways to fix this sink but you care about a select few. And the truly world-class plumber knows that and will gauge your interest in understanding the full solution. So at the end of the day, it’s STILL not about the gasket it’s about the communication surrounding the gasket and your comment actually reinforces this.
- dghlsakjg 3y ago
  I was looking for this response. I would be pissed if a plumber charged me to do it some way other than the right way. I'm paying for the sink to stop leaking, sure. But I'm also paying for the solution to be the correct, and best solution, especially in regards to fixing durable infrastructure. I get the author's point, but this was a poor analogy because there is a lot of ways for plumbing to be done wrong. A better analogy would probably be shipping a box from NY to LA. I don't particularly care if it is trucked, flown, or carried by a team of pigeons as long as it gets there when I was told it would get there.
al_be_back 3y ago
unless you buy an off-the-shelf product/solution, you're in effect buying a service of some sort and the low-level/technical implementation is just detail (coding, plumbing, rebuilding car engine etc). p.s. to me the OP read like a Cover Letter for a job application :)
paddw 3y ago
I think there are job where you very much need this mentality and then there are jobs where you don't have to bother much with the non-technical. Maybe the later are harder to find on demand, but there are plenty there. There are benefits and tradeoffs each way. I think the most important thing is to know what kind of person you are and what you want, and move towards finding work where you can be mostly actualized in that.
brigadier132 3y ago
Using Apple as an example seems silly because from what I see they agonize over the tiniest quality details in their products (and still often get it wrong). They spent almost 5 years and billions building an AR headset that possibly doesn't even have a market. This is the biggest and most successful business ever, how does that factor into the "generate business value" rhetoric.
otterpro 3y ago
I also became a guy who "solve problems" at a church that I volunteer as the media/AV/computer/tech guy. If the audio sounds weird in our live production or if the wedge speaker sounds too quiet or if the youtube stream looked too dark, I'm not going to say that we need to increase gain level on mic, change EQ to prevent feedback, change ISO setting on camera, etc. Instead, I'd tell them that I'd make some changes in the sound mixer and also adjust some settings in camera to fix those issues. I just tell them just enough for the audience/client/people to understand, without having to burden them with unnecessary detail.
nicechianti 3y ago
[dead]
projektfu 3y ago
My (somewhat outdated) experience with consultancies was that they depended a lot on the customer believing they had some wizardry, and that involved selling a lot of industrial jargon that the manager had a passing familiarity with. Whether the consultancy could produce a working product was secondary to the proprietary and arcane technology (300 combined years of experience or whatever) that they could bring to the sales meeting. The manager could rest well knowing that they had bought an intricate Patek Philippe of code, that might be as fit for purpose as a Citizen, if it works at all. Now, you can't sell a Patek Philippe by saying it's the most expensive out there. It has to be "the best" which is reflected in price. And you don't really ever make the comparison because it wouldn't reflect favorably. The aesthetics are, of course, top notch, but the sales copy is full of specs and descriptions of the arcane, lots of words to say it's the watch that goes ding. Marketing an upstart consultancy, you reach past the manager who makes these safe, expensive decisions, and you try to do the Apple thing mentioned in the article. You'll be laser-focused on providing value, lots of easy wins that the manager can show off at every opportunity. They will wonder who their wizard is that is doing all this with only 4 team members while the other project is using 30 and has nothing to show for it yet. Familiarity eventually causes the manager to short-circuit the upstart's sales pitch. They get 10 minutes into it and the manager says, "You mean you're just Agile? We already use Scrum. Boring." So the upstart will have to come up with new things to stay ahead of the established player.
havkom 3y ago
Excellent Article! I think many ppl here should not just read it once but several times and try to learn. Next step after that: — how will team work and nice&pleasant interaction with colleagues help me achieve things.
jamesgill 3y ago
See a related concept in product development, ‘jobs to be done’. In a sentence: people don’t pay for products, they pay for jobs to be done. There’s a famous example about milkshakes (YouTube).
landgenoot 3y ago
Another flavor of the original "Why would you hire a milkshake?" story [1]. [1]: https://www.youtube.com/watch?v=sfGtw2C95Ms https://www.youtube.com/watch?v=sfGtw2C95Ms
wduquette 3y ago
This is why I don't ask permission before eliminating technical debt: eliminating relevant technical data is part of solving the problem I'm currently addressing, and it's an implementation detail.
not_the_fda 3y ago
Sure you are being paid for a solution. But you are also probably being paid for a quality solution. I'm not sure you would want your house built by the contractor that took short cuts and did shoddy work. You might have roof over your head, but there will be more expensive problems later.
- htrp 3y ago
  > I'm not sure you would want your house built by the contractor that took short cuts and did shoddy work. You might have roof over your head, but there will be more expensive problems later. You might want to pick a better analogy as you've literally described all roofing construction at this point
- commandlinefan 3y ago
  I fear that we do ourselves a disservice by trying to draw physical-world analogies - if a roofing contractor screws things up, it's really easy for a non-roofing-contractor to see: the roof leaks. You call the guy and point out the leak so he fixes the leak. What's the equivalent of "leaky" software? Users can observe bugs, and they can observe slowness. Experienced developers know that what we call "poor quality" code is more prone to bugs and slowness, which they _do_ care about. They don't (and shouldn't) care about maintainability, they care about functionality: we should keep harping on performance and testability rather than esoteric "quality".
  - not_the_fda 3y ago
    If you don't pay attention to the quality of the software, eventually it becomes unmaintainable and you can no longer add features in a timely manner and you get crushed by your nimble competitors. One company I worked for was once the market leader, but over the years they failed to maintain the quality of the software. They kept adding more and more resources to get stuff out. Eventually it took them three years to get out a new release only for it to be so bug ridden they had to pull it. They are no longer in existence because they had the mentality of all that matters is features.
  - Tainnor 3y ago
baobabKoodaa 3y ago
The vast majority of coding jobs do not fall into the category of "company wants you to solve their problems". The vast majority is literally just paying people to code whatever it says in the Jira ticket, no matter how stupid or unclear that ticket is.
- thembones 3y ago
  This is spot on for 99% of companies out there.
killthebuddha 3y ago
Hot-ish take incoming: It's even less complicated than all this. You spend X on a feature to increase revenue by Y. You pay a plumber N so you don't have to pay a flooring guy 10N. In some orgs, if they're large, you could replace $ with $KPI, but $KPI should still be obviously quantifiable. If you're an engineer without obviously quantifiable KPIs (especially if you're a young-ish engineer with ambitions of becoming really excellent one day), you might consider selling your skills to a more serious employer.
eternityforest 3y ago
I think the problem is developers might think on multiple levels of abstraction at once all the time. When they see something, do their thoughts about it's inner working automatically come to mind? Code conissours don't quite get how nobody else cares, or even notices the code. Look at Etcher. it's 80MB to do what DD does. I used to use it until the Pi imaging utility came along. And for non pi stuff I still use it. It loads almost instantly on a modern machine, and it's safer that DD where you might accidentally hit the wrong key and have nothing stopping you. But a lot of developers would be bothered every time they use it by the fact it bundles electron. They have a sense of quality that goes beyond functionality, they want deep craftsmanship even if means more manual work, and the fact that complexity is not their problem doesn't matter, they don't like anything unnecessary anywhere. So when they talk to others, they're talking about their interest, which is trying to get to the core essence of what defines a problem in an elegant way, while the user just wants it solved in a way that means they don't have to think about it anymore. For the coder, the thinking is the whole point! Or at least for the typical fairly intelligent intellectual, idea driven personalities in the code world.
hintymad 3y ago
I remember there was heartbreaking posts years ago by an Australian author of a popular Delphi library. He basically said people loves his libraries but few would pay for them, so he gave up developing Delphi libraries all together. Over the years, what I learned is that individuals or companies do not like paying for technologies. They pay for products. In the case of technologies, companies rather pay for "boring" workflows. For instance, companies pay for control planes, so much so that Amazon's Open Search can be a billion-dollar business. On the other hand, few companies would pay for AWS AI's Key Phrase Extraction or Amazon Forecast, unless data processing is part of the service and is a huge pain for the companies.
BiteCode_dev 3y ago
Lot of comments here are replying the nature of the solution matters. E.G: "Sure you are being paid for a solution. But you are also probably being paid for a quality solution" or "Code can be the solution. Good code even more so" or "when you pay to get your car fixed, there's an implicit expectation that it will be fixed well enough that it doesnt break the same way again" But the article does address this: > Now, of course, this is a tad more subtle. > Different types of problems have different types of costs, consequences, and constraints. And solutions to those problems as well also have them. > When code is the solution, it has a cost, at the very minimum in time and man-hours. And constraints, such as licenses, NDA, platforms, versions, formats, resource limits... And of course, consequences, such as technical debt, electricity consumption, user experience and hiring difficulties. > While the clients don't care about the code, they care very much about those. > And so, as IT professionals, we must communicate talking about that. Not about the code. Of course the quality of the solution matters, but it any good thing has a price. Therefore you have to present it with the price, and then your opinion on the whether it's worth it.
agumonkey 3y ago
Always the same story. Nobody "cares" about how it's done, until they do. If the plumber throws crazy glue and scotch tape enough so it stops leaking for a day, is the job done ? There are principles to master in how to make a job good enough considering the time / budget constraints.

210 points by BiteCode_dev 3y ago

soumid 3y ago

[flagged]

BiteCode_dev 3y ago
It seems you haven't read the article.

mcqueenjordan 3y ago

Also known as the “jobs to be done” pattern.

zelphirkalt 3y ago

I disagree with some of the things the article describes. Not that they aren't real or that the world works differently, but with those things themselves. For example: (1) It should always be ones goal to improve ones technical skills, not only in the beginning of ones career. Too often have I seen bad code or lack of knowledge about computer programming concepts, that people ought to know, considering the time they spent in their career. Those things will result in "solutions" but those solutions might not be the most maintainable and understandable. Fine if you switch jobs every 2 years and never have to deal with the aftermath, but not fine for people, who value quality. All your communication skills won't make up for a brittle base due to insufficient technical skills. (2) To let others dictate, how you develop professionally, being the ultimate yes-sayer. Improve the way you yourself value and see as important and stick to your guns. Not everyone needs to go along career paths that some company with mediocre management has laid out for them. Not everyone needs to become a talker. (3) Perhaps the title is a bit too extreme. Code can be the solution. Good code even more so. Personally that's what I want to do. Write code to solve problems. Of course, only write it, when it is necessary. Who wants to write code only to have it be discarded, because it was not needed in the first place. (OK maybe sometimes one does, for the learning experience.)

FrustratedMonky 3y ago
Yeah. The article has the right idea in general. But, It's pretty thin, there are entire books written on this subject that dig into the 'nuance'. I've also had consultants get a bit to 'hand-wavy' like described, and then I don't trust they can code either.
- acedTrex 3y ago
  I feel like the hand wave should be the default until actually asked then you can dive into specifics.
chadash 3y ago
> Code can be the solution. Good code even more so. I think I agree with the author here. Code is a tool. This is like saying "a wrench can be the solution and a good wrench is even more valuable". I'm sure that car mechanics have very strong opinions about various wrenches. But I'm paying to get my car fixed. Sure, it's nice to hear that your shop has the latest equipment, but at the end of the day, the thing that matters most is that you can fix my car. Even as a developer, I hardly care about the code quality or what language you use if you provide a good and reliable service. I've never thought to myself, geez, I love AWS, but I really wish they'd move away from Java.
- kraftman 3y ago
  You would if their services crashed every day though right? Like when you pay to get your car fixed, there's an implicit expectation that it will be fixed well enough that it doesnt break the same way again for a certain amount of time, and it doesnt make anything else break. If you found out that the garage was using wooden wrenches that broke 10% of the time and they passed that cost onto you, or occasionally broke and damaged the car, but didn't in your case, you wouldnt be like 'oh well, they fixed the problem, Ill keep going back to them'.
  - chadash 3y ago
    i'm trying to think of the coding equivalent of wooden wrenches? Let's say that's an app written entirely with VBA. If I perceive that it solves my problems, then for most use cases, i'd be fine with it. I guess if it's running my bank account or it's a platform for deploying my code, maybe i'd care somewhat, but in 99% of cases, i wouldn't. But the reality is that most code is written in a language that's good enough. It's a metal wrench that might be showing some rust. Do I think that PHP is a good language to start a project with today? Of course not. Do I care if you wrote your site 15 years ago and it still runs on PHP? Not really.

Greenpants 3y ago

This is indeed a good point to keep in mind. I do tend to forget sometimes. As a perfectionist I'm always planning code refactors in my mind, but rarely do they see the light of day; they're often minimal and don't add anything to the solution. There's very little added value. Know your audience – know what they need, and you can develop accordingly.

srazzaque 3y ago

Good read, a lot that resonated with me. My comms (written and verbal) to stakeholders are something I'd rate as "OK". But, on occasion I still do catch myself out diving into tech talk at the wrong times. I'd add that with a certain level of seniority, for those developers that enjoy working directly with clients and stakeholders, it's expected that you can translate in both directions. That is: not just going from "tech to non-tech", but also shaping a "non-tech" requirement into an actual solution. Clients will rarely ask for redundancy, persistence or ACID compliance. But they will say things like "I want some sort of completeness check, and I can't have the system drop any messages from the exchange."

wheelerof4te 3y ago

The clients pay me to create quality products or services. The "quality" is key. I can stop the leak, but if I did it badly, the sink will start leaking again. And it will leak worse.

jdsullivan 3y ago

The more important and general wisdom: know your audience. You will sometimes have clients with deep technical backgrounds that expect a sufficient level of detail to have any faith or trust in your solutions. You need to be able to tailor your communication based on the situation and the expectations of the audience in question. This is never binary and can be especially challenging when you need to communicate to multiple people at the same time that each require different levels of detail.

deleted 3y ago
[deleted]
AmIDev 3y ago
This is something I struggle with. I have a weekly meeting which includes TL, Manager, PM and sometimes Staff engineers, Data analysts, Managers of downstream teams etc. I try to keep the details to the lowest denominator, which usually means mentioning what the problem is and what the proposed solution is in few lines. But eventually someone will ask for more details, and then the conversation veers off to technical discussion that I am sure the PMs and Analysts don't understand.
- kupopuffs 3y ago
  tech design meetings shouldn't have product. and if this is a demo, then it should only really require stakeholders. if the meeting is for product to share their vision or requirements, save the tech talk for later its very tempting to get into the weeds of things, but this can be "parking lotted" as the kids say
BiteCode_dev 3y ago
Indeed, but this general wisdom is too vague to be useful on its own. When I was young, I heard it many times, and couldn't make anything from it. What's the audience exactly? How do I know them? Once I know them, what am I suppose to do? And all that stuff is contextual, so what are we talking about really? When learning to negociate, knowing your audience is a very different thing than when trying to teach. Very few people are able to pull it off accross fields. So I decided to write an article that targets a specific case with a concrete application and examples. This would have been more useful to me back then.

xen0 3y ago

Sometimes I know what I want, and if a salesman starts trying to sell me a 'concept' or a 'lifestyle' instead of a car, I'm walking away.

stavros 3y ago
If you're at the lot, you've already been sold on the concept and the lifestyle, and you're there to buy. Amazon doesn't try to tell you how great sweaters are when you're on the checkout page of buying one.
- justinclift 3y ago
  > If you're at the lot ... That misses a whole bunch of reasons a person could be "at the lot" other than for buying. Easy, real world examples: * You're killing time while waiting for the other half at a nearby store * There's a whole group of vehicle "lots" next to each other, so you're taking a look at all of them for a better understanding of your options * Your car is being repaired / in for a service (or similar) (etc)
  - stavros 3y ago
    > * You're killing time while waiting for the other half at a nearby store I wouldn't kill time at a fertilizer store if I didn't have a garden, though. > * There's a whole group of vehicle "lots" next to each other, so you're taking a look at all of them for a better understanding of your options This still means that I realize the value of a car for me. > * Your car is being repaired / in for a service (or similar) Same as the one above here. Selling you on the concept/lifestyle is for when you don't yet know you need a specific thing. When you're at the lot, you're past that.
    - Miraltar 3y ago
      Lifestyle and concepts in this context can be more specific. This particular car would be perfect for your daily routine because of this, this and this... Oh but this one allows you to take your children on holidays conveniently beacause of that... Yes you already have/want a car but you might still be convinced to buy a car you didn't plan.

Artgor 3y ago

In general I agree. But if this approach is applied for the same system many times in a row, it can cause technical debt.

bluedino 3y ago

This works the other way around. You'll get a technical project manager, and they'll bring in a consultant to do some programming. "All you guys need to do is write a little code to interface X with Y, it should only take you a couple days" They don't think, "you'll need to get with this vendor, use this outdated software, follow these restrictions, make sure the UI matches up with the other program, interface with this authentication library..." That's all part of "Add UPS shipping support to our CRM software"

quickthrower2 3y ago
Just a checkbox. Why are you still working on it after a week!
- vxNsr 3y ago
  At that point you give them the checkbox. “Here it is, you’re right it was sooo easy, oh you wanted it to do something… yea that’s why it takes longer”
- ooterness 3y ago
  It's all blocked because Galactus still doesn't support ISO timestamps. https://youtu.be/y8OnoxKotPQ https://youtu.be/y8OnoxKotPQ
  - kirubakaran 3y ago
    Common mistake. It's Omega Star that doesn't support ISO timestamps even though they said they would, and Galactus (which supports ISO timestamps) is getting deprecated by the end of the month.
    - quickthrower2 3y ago
      It is Omega Star that doesn't support ISO timestamps, correct, but it is EKS (Entropy [K]haos Service?) that getting deprecated at the end of the month. Without that you can't provide a time stamp for the end of the universe to Galactus. Having said that, I am probably wrong too.

quickthrower2 3y ago

Yet every interview I have been to has had several coding tests, take homes and technical interviews. Your code is reviewed, and someone decides after 6 months if you are up to task. As an employee you can’t find an external solution and resell it with some smooth talking for double the price and go play golf. Rather you will be subjected to agile practices and if unlucky logging your hours against tickets. Most coders are actually paid to code. (trying to do non coding work beneficial to the business is actually a struggle unless it is in your assigned role!)

swalsh 3y ago
People don't pay for welding, they pay for buildings, cars etc... but they also are going to be real disappointed if the welds fail.
- BSEdlMMldESB 3y ago
  welding needs to be repeated for every building code is written once, then everybody can copy it to make use of it why is this such a huge problem? what to do about it? I have a lot of opinions around this but it doesn't matter
  - pdimitar 3y ago
    Code is written once? Can't be farther from the truth. Code has to be iterated on, quite often too.
    - BSEdlMMldESB 3y ago
      to write is different from to rewrite but c'mon. I'm referring to the fact that code can be made into libraries, or APIs if you're so keen on collecting rent and then as a digital asset, the library can be copied and distributed, hence code can be written once (one team writes it) then everybody else can use it with no additional cost, (again, unless you actually want to tax/collect-rent from other people, then you make up this additional cost)

smallstepforman 3y ago

Using the analogy of a car, I’m not buying ANY car but a SPECIFIC car with features and quality that meet my requirements. My client is not getting ANY code, but featured and performant code. My client is fed up with basic code, they want “quality” and are paying appropriately for it. So yes, there are clients that pay for “quality” code because they do want more than just a solution.

duncan-donuts 3y ago
Nah I think the OP post still works here. You might have requirements of a car that only some niche manufacturer can meet because you have a very specific problem to solve. Let’s say you’re in a wheelchair and you need a vehicle that is accessible for you. Your solution you’re paying for is more specific than others.
- jacobr1 3y ago
  And similarly, nobody is paying for the blueprints, or CAD files, or assembly or whatever, they just want the car. There might be people that DO want those intermediate outputs (other car builders, hobbyists) but not the usual car-buyer, even one with very-specific needs. The one exception to this might be, the car-buyer that does intend to heavily modify their vehicle, might value to the availability its creative inputs so that modification later on is easier.
zepolen 3y ago
Exactly. One plumber will fix the leak with a new gasket. The other will fix the leak with duct tape. Both will solve the customers immediate need and stop the leak.

yobbo 3y ago

> They told their customers: "1000 Songs in Your Pocket". That is talking about specs, and it is exactly what the competition did too. Here in the unit "number of songs". Maybe most people at the time couldn't translate GBs into number of songs, but nowadays bandwidth or "surf" is talked about in terms of GBs because it has become familiar through experience. The iPod had better specs and better design. The original Jobs presentation even puts up a table or 2x2 illustrating how the iPod specs would be superior. Obviously, one adapts language to audience, but I've never seen a case where this is the real reason for success or failure.

scarface_74 3y ago
> The iPod had better specs and better design. It in fact had less space than the Nomad and was kind of lame On top of that, it didn’t have wireless! /s.
- rvbissell 3y ago
  > It in fact had less space than the Nomad and was kind of lame Rob Malda, is that you?
- stonemetal12 3y ago
  But would a Nomad it in your pocket? I have never seen a Nomad IRL, the pictures on wikipedia make it look like the size of a CD player, not something that would fit in my pocket.
  - scarface_74 3y ago
    I can’t blame you for not getting the reference. It is over 20 years old now. https://m.slashdot.org/story/21026 https://m.slashdot.org/story/21026
  - 1-more 3y ago
    Yeah the key differentiator was that the other hard disk MP3 players up to that point used 2.5" laptop harddrives and removable AA batteries and fit in a cargo pocket. The iPod used a 1.8" harddrive and a slim built-in rechargeable battery and fit in a jeans pocket (it was pretty huge for a shirt pocket but could fit in there if you didn't care about it ruining your lines). The term "laptop harddrives" of course confuses the issue: the Macbook Air first shipped with a 1.8" harddrive before it changed to flash storage.

ghoshbishakh 3y ago

A typo: "well enought" -> "well enough"

Jarmsy 3y ago
The whole article is clearly written by someone struggling with English, with no checking or editing. They use 'seldom' in a way that makes no sense, where I guess they meant 'hardly'. Then there's 'hilight' instead of highlight. That's just in the first few lines.

RcouF1uZ4gsC 3y ago

I think this is wrong: You are getting paid to code. The person's problem is not code, but if code is the solution, that is what you are getting paid for. The plumber is getting paid to change a gasket. If you look at the invoice, it won't say "water management" but it will include the gasket and labor. Same for the car. If you look at the invoice, if won't say "personal transportation, instead you will see the car and the options that you paid for. Same if you go to the doctor. It will list the various procedures and diagnosis and bill for those. This conflates two issues: deciding the solution to your problem, and paying for the solution. Marketing and sales is about convincing people that what you are selling is the solution to their problem. For example, car ads try to convince you that the specific car is the solution to going places in comfort with status. A beer ad tries to convince you that this particular beer is the solution for you having a great time with friends. You actually then pay for the concrete car or beer, etc.

alexghr 3y ago

> So keep the technical talk to your peers, unless the client explicitly asks for it. This! Adapt the message to the target audience. The code we write is an abstraction, it takes some input and produces an output. For many it's a black box or can be thought of as a black box. Start high and go lower and lower until you reach the right level of detail for the person you're communicating with.

swayvil 3y ago
Sometimes the client wants to talk about code. He wants to be involved in the technical decisions. But he doesn't know diddly about code. So you have these frustrating conversations and try not to call the client an idiot.

dataviz1000 3y ago

A power plant stopped working. None of the engineers could fix it. They called the retired engineer who designed the power plant years ago for help. He arrives, looks at the control room panels, walks through the plant, pulls out a screw driver, and turns a screw. The power plant starts working again. He quickly writes an invoice for $100,010. The manager complains asking why he is charging so much when he only turned one screw. The engineer replies, "I'm charging $10 for turning the screw and $100,000 for knowing which screw to turn."

eesmith 3y ago
That story was old even before my parents were born. https://quoteinvestigator.com/2017/03/06/tap/ https://quoteinvestigator.com/2017/03/06/tap/ and https://www.snopes.com/fact-check/know-where-man/ https://www.snopes.com/fact-check/know-where-man/ . Instead of making up a new variant, you might use one with a bit more historical lineage. My favorite version involves Charles Proteus Steinmetz, the deservedly named "Wizard of Schenectady", from this 1965 letter to the editor at Life: https://books.google.co.uk/books?id=QFMEAAAAMBAJ&lpg=PA16&pg=PA27&redir_esc=y&hl=en#v=onepage&q&f=true https://books.google.co.uk/books?id=QFMEAAAAMBAJ&lpg=PA16&pg... taking place supposedly around 1920 (see https://history.stackexchange.com/questions/43438/in-what-year-did-charles-proteus-steinmetz-fix-fords-generator-for-the-famed-1 https://history.stackexchange.com/questions/43438/in-what-ye... ). That still doesn't mean it actually happened, but you might get an up-vote by Steinmetz fans. ;)
lispisok 3y ago
Great Facebook boomer copypasta but my takeaway from this story is the power plant was designed very poorly if one loose screw can take down the whole system and is not diagnosable by anybody who didnt design the system. The retired engineer did a very bad job.

jroseattle 3y ago

I was around for the mp3 "revolution", so I'll add to the author's discussion point about the ipod. The thousand-songs-in-your-pocket sales pitch was more than lifestyle/concept -- it was an actual feature. All of the other players at the time were big & bulky because the components they used for storage & battery required the corresponding form factor. The "pocket" part of the sales pitch was exactly that: the ipod physically fit in your pocket because the components were smaller and more integrated. In the stage demoes by Jobs, he shoves the ipod into his jeans. To the author's point about "you pay for the problem it solves, or the needs/wants it fulfills", the implied need here was that you need this to be small and out-of-the-way -- not a miniature home-stereo attached to your belt. And not to pick on the author, but I don't find the ipod reference very applicable to the case of communicating with your consulting clients. Sure, you have to speak to your audience -- but direct 1:1 contact with a handful of stakeholders is hella different from millions of consumers who never asked you for a specific set of features and a timeline.

plorkyeran 3y ago
It wasn’t just that it physically fit in your pocket - it also worked in your pocket. I had pants at the time which I could fit a portable CD player in, but walking around without the music skipping required carefully holding it steady. The earlier non-flash mp3 players tended to have HDDs that similarly weren’t great with motion while in use.
throwaway3655 3y ago
The reality distortion field is strong. An mp3 player was in every kid's jeans pocket before the ipod was even announced.[0] Its innovation was costing twice as much and having white earphones, which made it suitable as a wealth-signaling fashion accessory. [0] https://en.wikipedia.org/wiki/Portable_media_player#The_MP3_standard https://en.wikipedia.org/wiki/Portable_media_player#The_MP3_...
- jroseattle 3y ago
  True, except for the every-kid part. The market was pretty fragmented back then. Nonetheless, I was referring to the sales pitch. And Jobs never let facts get in the way of a good story. :-)

gorpomon 3y ago

Overall I like posts like these, as they are a reminder that you're not really paid for agonizing over eloquent or great code, but just code that "gets the job done". But then if you over-index on this viewpoint, you'll end up needing posts which remind you that this is a craft and that code needs some agonizing over. What I've been pondering lately is another way to sum this up that is more future focused: Let's say a genie walks into your project and says that you can have 1.5 times the features you have right now, for 3x the code. The genie promises that the code will be "alright, maybe just kind of a bit bad". I think around 2/3 of developers would say no, but I suspect 2/3 of people in product management, sales, marketing, etc would say yes. Everyone would be sympathetic to the problems this would create, but the allure of getting 1.5X ahead on your roadmap is probably too hard to ignore for those other disciplines. It's basically accelerating all your other work streams by 1.5, at the expense of potentially bogging down dev. Obviously, countless caveats exist, but it does in general feel right, and feels like it hints at the fundamental causes of tension between business and development.

wbl 3y ago
How much does it bog down? If for the next two years you're adding features at half the rate but you got a five year boost you're still head and some of that work can simplify the situation.
- gorpomon 3y ago
  Yeah that's the thing, it's hard to say how much you are bogged down. As time goes on the value of the 1.5x multiplier increases in value, but then you also run the risk of massive spaghetti code (more or less, depends on what the genie considers good). I don't know if there's great value in trying to figure out if you would quantitatively get ahead though. I think the value is in just realizing that some groups are inclined to perhaps take that risk, and some groups are not.
- josephg 3y ago
  If your code has increased by 3x, that means 2/3 of the entire project is unknown to your developers. It’ll take a lot of work to just get everyone across that much extra code. To say nothing of how much work it would be to tame it. I agree with the GP. Business people would probably salivate over this, but if it were up to me I’d want to say no.

jmpeax 3y ago

> If your sink is leaking, you might call a plumber to fix it. > But you don't really pay the plumber for putting a new gasket in. > In fact, you don't care about the gasket, you care about not having you sink leaking. I care about the gasket. If I want the sink to not leak then one way is to not use the tap/faucet. There are countless ways to fix the problem of your sink leaking, but only very few that you really want. Knowing your problem is important so that you don't waste time and money on charlatans. I care about the damned gasket.

polishdude20 3y ago
Yeah, you may not KNOW you care about the gasket, you may not even know what a gasket is or where it is, but you care about it because you care about the outcome it gives you.
blitz_skull 3y ago
No you don’t. You think you do, but you really don’t. You care about the problem going away. Sure maybe YOU care about the gasket, but there’s some other technical domain in your life that can sub in and the metaphor stands. No one is technical enough in every arena of life to care about the gasket. Also to really stretch this metaphor to its limit, it’s exactly as the author said—there ARE countless ways to fix this sink but you care about a select few. And the truly world-class plumber knows that and will gauge your interest in understanding the full solution. So at the end of the day, it’s STILL not about the gasket it’s about the communication surrounding the gasket and your comment actually reinforces this.
dghlsakjg 3y ago
I was looking for this response. I would be pissed if a plumber charged me to do it some way other than the right way. I'm paying for the sink to stop leaking, sure. But I'm also paying for the solution to be the correct, and best solution, especially in regards to fixing durable infrastructure. I get the author's point, but this was a poor analogy because there is a lot of ways for plumbing to be done wrong. A better analogy would probably be shipping a box from NY to LA. I don't particularly care if it is trucked, flown, or carried by a team of pigeons as long as it gets there when I was told it would get there.

al_be_back 3y ago

unless you buy an off-the-shelf product/solution, you're in effect buying a service of some sort and the low-level/technical implementation is just detail (coding, plumbing, rebuilding car engine etc). p.s. to me the OP read like a Cover Letter for a job application :)

paddw 3y ago

I think there are job where you very much need this mentality and then there are jobs where you don't have to bother much with the non-technical. Maybe the later are harder to find on demand, but there are plenty there. There are benefits and tradeoffs each way. I think the most important thing is to know what kind of person you are and what you want, and move towards finding work where you can be mostly actualized in that.

brigadier132 3y ago

Using Apple as an example seems silly because from what I see they agonize over the tiniest quality details in their products (and still often get it wrong). They spent almost 5 years and billions building an AR headset that possibly doesn't even have a market. This is the biggest and most successful business ever, how does that factor into the "generate business value" rhetoric.

otterpro 3y ago

I also became a guy who "solve problems" at a church that I volunteer as the media/AV/computer/tech guy. If the audio sounds weird in our live production or if the wedge speaker sounds too quiet or if the youtube stream looked too dark, I'm not going to say that we need to increase gain level on mic, change EQ to prevent feedback, change ISO setting on camera, etc. Instead, I'd tell them that I'd make some changes in the sound mixer and also adjust some settings in camera to fix those issues. I just tell them just enough for the audience/client/people to understand, without having to burden them with unnecessary detail.

nicechianti 3y ago

[dead]

projektfu 3y ago

My (somewhat outdated) experience with consultancies was that they depended a lot on the customer believing they had some wizardry, and that involved selling a lot of industrial jargon that the manager had a passing familiarity with. Whether the consultancy could produce a working product was secondary to the proprietary and arcane technology (300 combined years of experience or whatever) that they could bring to the sales meeting. The manager could rest well knowing that they had bought an intricate Patek Philippe of code, that might be as fit for purpose as a Citizen, if it works at all. Now, you can't sell a Patek Philippe by saying it's the most expensive out there. It has to be "the best" which is reflected in price. And you don't really ever make the comparison because it wouldn't reflect favorably. The aesthetics are, of course, top notch, but the sales copy is full of specs and descriptions of the arcane, lots of words to say it's the watch that goes ding. Marketing an upstart consultancy, you reach past the manager who makes these safe, expensive decisions, and you try to do the Apple thing mentioned in the article. You'll be laser-focused on providing value, lots of easy wins that the manager can show off at every opportunity. They will wonder who their wizard is that is doing all this with only 4 team members while the other project is using 30 and has nothing to show for it yet. Familiarity eventually causes the manager to short-circuit the upstart's sales pitch. They get 10 minutes into it and the manager says, "You mean you're just Agile? We already use Scrum. Boring." So the upstart will have to come up with new things to stay ahead of the established player.

havkom 3y ago

Excellent Article! I think many ppl here should not just read it once but several times and try to learn. Next step after that: — how will team work and nice&pleasant interaction with colleagues help me achieve things.

jamesgill 3y ago

See a related concept in product development, ‘jobs to be done’. In a sentence: people don’t pay for products, they pay for jobs to be done. There’s a famous example about milkshakes (YouTube).

landgenoot 3y ago

Another flavor of the original "Why would you hire a milkshake?" story [1]. [1]: https://www.youtube.com/watch?v=sfGtw2C95Ms https://www.youtube.com/watch?v=sfGtw2C95Ms

wduquette 3y ago

This is why I don't ask permission before eliminating technical debt: eliminating relevant technical data is part of solving the problem I'm currently addressing, and it's an implementation detail.

not_the_fda 3y ago

Sure you are being paid for a solution. But you are also probably being paid for a quality solution. I'm not sure you would want your house built by the contractor that took short cuts and did shoddy work. You might have roof over your head, but there will be more expensive problems later.

htrp 3y ago
> I'm not sure you would want your house built by the contractor that took short cuts and did shoddy work. You might have roof over your head, but there will be more expensive problems later. You might want to pick a better analogy as you've literally described all roofing construction at this point
commandlinefan 3y ago
I fear that we do ourselves a disservice by trying to draw physical-world analogies - if a roofing contractor screws things up, it's really easy for a non-roofing-contractor to see: the roof leaks. You call the guy and point out the leak so he fixes the leak. What's the equivalent of "leaky" software? Users can observe bugs, and they can observe slowness. Experienced developers know that what we call "poor quality" code is more prone to bugs and slowness, which they _do_ care about. They don't (and shouldn't) care about maintainability, they care about functionality: we should keep harping on performance and testability rather than esoteric "quality".
- not_the_fda 3y ago
  If you don't pay attention to the quality of the software, eventually it becomes unmaintainable and you can no longer add features in a timely manner and you get crushed by your nimble competitors. One company I worked for was once the market leader, but over the years they failed to maintain the quality of the software. They kept adding more and more resources to get stuff out. Eventually it took them three years to get out a new release only for it to be so bug ridden they had to pull it. They are no longer in existence because they had the mentality of all that matters is features.
- Tainnor 3y ago

baobabKoodaa 3y ago

The vast majority of coding jobs do not fall into the category of "company wants you to solve their problems". The vast majority is literally just paying people to code whatever it says in the Jira ticket, no matter how stupid or unclear that ticket is.

thembones 3y ago
This is spot on for 99% of companies out there.

killthebuddha 3y ago

Hot-ish take incoming: It's even less complicated than all this. You spend X on a feature to increase revenue by Y. You pay a plumber N so you don't have to pay a flooring guy 10N. In some orgs, if they're large, you could replace $ with $KPI, but $KPI should still be obviously quantifiable. If you're an engineer without obviously quantifiable KPIs (especially if you're a young-ish engineer with ambitions of becoming really excellent one day), you might consider selling your skills to a more serious employer.

eternityforest 3y ago

I think the problem is developers might think on multiple levels of abstraction at once all the time. When they see something, do their thoughts about it's inner working automatically come to mind? Code conissours don't quite get how nobody else cares, or even notices the code. Look at Etcher. it's 80MB to do what DD does. I used to use it until the Pi imaging utility came along. And for non pi stuff I still use it. It loads almost instantly on a modern machine, and it's safer that DD where you might accidentally hit the wrong key and have nothing stopping you. But a lot of developers would be bothered every time they use it by the fact it bundles electron. They have a sense of quality that goes beyond functionality, they want deep craftsmanship even if means more manual work, and the fact that complexity is not their problem doesn't matter, they don't like anything unnecessary anywhere. So when they talk to others, they're talking about their interest, which is trying to get to the core essence of what defines a problem in an elegant way, while the user just wants it solved in a way that means they don't have to think about it anymore. For the coder, the thinking is the whole point! Or at least for the typical fairly intelligent intellectual, idea driven personalities in the code world.

hintymad 3y ago

I remember there was heartbreaking posts years ago by an Australian author of a popular Delphi library. He basically said people loves his libraries but few would pay for them, so he gave up developing Delphi libraries all together. Over the years, what I learned is that individuals or companies do not like paying for technologies. They pay for products. In the case of technologies, companies rather pay for "boring" workflows. For instance, companies pay for control planes, so much so that Amazon's Open Search can be a billion-dollar business. On the other hand, few companies would pay for AWS AI's Key Phrase Extraction or Amazon Forecast, unless data processing is part of the service and is a huge pain for the companies.

BiteCode_dev 3y ago

Lot of comments here are replying the nature of the solution matters. E.G: "Sure you are being paid for a solution. But you are also probably being paid for a quality solution" or "Code can be the solution. Good code even more so" or "when you pay to get your car fixed, there's an implicit expectation that it will be fixed well enough that it doesnt break the same way again" But the article does address this: > Now, of course, this is a tad more subtle. > Different types of problems have different types of costs, consequences, and constraints. And solutions to those problems as well also have them. > When code is the solution, it has a cost, at the very minimum in time and man-hours. And constraints, such as licenses, NDA, platforms, versions, formats, resource limits... And of course, consequences, such as technical debt, electricity consumption, user experience and hiring difficulties. > While the clients don't care about the code, they care very much about those. > And so, as IT professionals, we must communicate talking about that. Not about the code. Of course the quality of the solution matters, but it any good thing has a price. Therefore you have to present it with the price, and then your opinion on the whether it's worth it.

agumonkey 3y ago

Always the same story. Nobody "cares" about how it's done, until they do. If the plumber throws crazy glue and scotch tape enough so it stops leaking for a day, is the job done ? There are principles to master in how to make a job good enough considering the time / budget constraints.