[HN Gopher] Nobody ever paid me for code
___________________________________________________________________
Nobody ever paid me for code
Author : BiteCode_dev
Score : 195 points
Date : 2023-08-13 11:17 UTC (1 days ago)
(HTM) web link (www.bitecode.dev)
(TXT) w3m dump (www.bitecode.dev)
| BiteCode_dev wrote:
| 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.
| projektfu wrote:
| 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.
| killthebuddha wrote:
| 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.
| RcouF1uZ4gsC wrote:
| 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.
| eternityforest wrote:
| 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.
| alexghr wrote:
| > 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 wrote:
| 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.
| soumid wrote:
| [flagged]
| BiteCode_dev wrote:
| It seems you haven't read the article.
| dataviz1000 wrote:
| 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."
| lispisok wrote:
| 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.
| eesmith wrote:
| That story was old even before my parents were born.
| https://quoteinvestigator.com/2017/03/06/tap/ and
| 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...
| taking place supposedly around 1920 (see
| 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. ;)
| havkom wrote:
| 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.
| jdsullivan wrote:
| 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]
| AmIDev wrote:
| 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.
| xen0 wrote:
| 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 wrote:
| 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.
| xen0 wrote:
| The job of BMW's advertisers isn't to convince me to buy a
| car.
|
| It's to convince me to buy their car instead of one from
| Tesla or Mercedes. And me walking into a BMW dealership does
| not mean I've decided to conduct business with them.
| justinclift wrote:
| > 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 wrote:
| > * 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 wrote:
| 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.
| m_0x wrote:
| > I wouldn't kill time at a fertilizer store if I didn't
| have a garden, though.
|
| You would if you had nothing to do other than walking
| into a fertilizer store. Very small chance of happening
| that to you, but I do like going into stores and see what
| they sell even if I don't need anything in there for me.
|
| I might learn something.
| justinclift wrote:
| > This still means that I realize the value of a car for
| me.
|
| That wasn't what you were presenting in that sentence
| though, which is what I was responding to. ;)
| makapuf wrote:
| Often if I want <product> from <company with 1 famous
| product> I go to the page <company.com> and _might_ find
| <product> somewhere, buried under "solutions" / "contact me
| for inquiry of your solution" pages.
|
| If I want to buy a mug I don't need to delegate my Coffee
| solution choosing expertise.
| almostnormal wrote:
| > If I want to buy a mug I don't need to delegate my Coffee
| solution choosing expertise.
|
| Sometimes I wish I could delegate purchase of trivial
| items, especially if there are too many options to choose
| from. The investment of time can be excessive, with less
| than satisfying results.
|
| Of course I would not like to delegate it to the
| manufacturers or vendors.
| WesolyKubeczek wrote:
| > if a salesman starts trying to sell me a 'concept' or a
| 'lifestyle' instead of a car, I'm walking away.
|
| In these places, you're also getting berated for coming in with
| a XY problem on your way out.
| brigadier132 wrote:
| 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.
| landgenoot wrote:
| Another flavor of the original "Why would you hire a milkshake?"
| story [1].
|
| [1]: https://www.youtube.com/watch?v=sfGtw2C95Ms
| wduquette wrote:
| 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.
| hintymad wrote:
| 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.
| mcqueenjordan wrote:
| Also known as the "jobs to be done" pattern.
| not_the_fda wrote:
| 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.
| commandlinefan wrote:
| 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 wrote:
| 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 wrote:
| I sometimes use software that is incredibly buggy and seems
| unable to add simple features people have been asking for for
| years (even though they are promising to implement it).
|
| I obviously can't say exactly what the precise problems with
| the code base are, but it's rather easy to conclude that it
| must be a total mess.
| htrp wrote:
| > 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
| bluedino wrote:
| 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 wrote:
| Just a checkbox. Why are you still working on it after a week!
| ooterness wrote:
| It's all blocked because Galactus still doesn't support ISO
| timestamps.
|
| https://youtu.be/y8OnoxKotPQ
| kirubakaran wrote:
| 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.
| m_0x wrote:
| > Why are you still working on it after a week!
|
| That's a failure on the developer's communication. If
| everyday you find a new challenge, then everyday you must
| communicate that new challenge.
|
| Code changes/features is not one to one. It's a bunch of
| changes to provide one feature. And remember we can at best
| estimate the time it will take us. Estimates are often wrong
| because of things we didn't know that we didn't know.
| [deleted]
| vxNsr wrote:
| 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"
| jroseattle wrote:
| 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 wrote:
| 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 wrote:
| 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_...
| morelisp wrote:
| First, not _nearly_ every kid. When the iPod came out my
| PMP-300 was still relatively novel; much more common was MP3
| CD players, which skipped like hell even if you could put
| them in your pocket.
|
| The market was also divided in a way that's hard to imagine
| today, something like an iFP or PMP was like taking a single
| tape/CD with you. But the Jukebox (the infamous Nomad) and
| some other lines were really "put _all_ your music here; this
| now _is_ your music collection. " The iPod was the first
| pocket-sized player that supported this mode. (And the iPod
| Shuffle probably the last in the line of the former style.)
| jroseattle wrote:
| 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. :-)
| rkho wrote:
| > An mp3 player was in every kid's jeans pocket before the
| ipod was even announced
|
| This is a strange statement. I grew up in the Bay Area and a
| CD player was in my hands/in the back pocket of my backpack
| for the longest time. It wasn't until the second iPod Mini
| that I even knew what an iPod was.
| hbn wrote:
| Didn't the iPod blow all of the other MP3 players out of the
| water in storage capacity cause Apple got some of the first
| access to tiny HDD's while everything else was using flash
| storage?
| tiltowait wrote:
| It (in)famously had "less space than a Nomad", but from my
| >20-year-old anecdotal experience, everyone I knew then had
| Diamondback Rios and the likes with maybe 64MB of CF
| storage, as you said.
| yamazakiwi wrote:
| Every kid did not have an mp3 player. I saw a wide variety of
| music players. No single product came close to market
| domination until the ipod. Kid's were all using different
| products like mini-disc players, cd players, mp3 players,
| walkmans, it was all over the place.
| pessimizer wrote:
| I disagree. By then, every kid had an mp3 player. Every
| other choice was big and clunky.
| yamazakiwi wrote:
| It could be location based but you are wrong for most
| areas on planet earth. Many kids went from cd player to
| ipod because mp3 players were too expensive as a
| replacement for something you had that already solution
| for. Convincing your parents you needed more songs was
| laughable at the time. If anything, more children got mp3
| players AFTER the iPod became popular. The excuse for a
| better product was more palatable due to the iPod's
| popularity.
| throwaway3655 wrote:
| People got ipods because they were the inexpensive
| option? No, not on planet Earth.
|
| The ipod was $400. Low-end mp3 players were $100.
|
| Here[0] is a review from 2002 for the MPIO DMG mp3
| player, which criticizes its 139-219 dollar price range
| for being too expensive.
|
| [0] https://the-
| gadgeteer.com/2002/03/13/mpio_dmg_mp3_player_rev...
| pessimizer wrote:
| Yes. This entire thread is bizarre. The iPod, when it was
| introduced, was dollar for dollar easily the worst mp3 player
| on the market. It won because it was massively marketed,
| people found it pretty, it was tied in with Apple's other
| products and a marketplace, and the same people who wanted a
| candy-colored computer (and a candy-colored New Volkswagen
| Beetle that matched it) wanted the thing in the billboards
| with the MTV silhouette dancing against a brightly colored
| background.
|
| I'd say that their innovation was that round touch slider
| thingie that added nothing to the functionality but
| confusion, but was fun to use.
| m_0x wrote:
| > I was around for the mp3 "revolution", so I'll add to the
| author's discussion point about the ipod.
|
| There won't be an agreement here because it's just semantics.
| The opposite sounds very true as well. Let's reverse it.
|
| "The thousand-songs-in-your-pocket sales pitch was more than a
| feature-- it was a lifestyle/concept."
|
| It sounds.... exactly the same to me. Both words (lifestyle vs
| feature) have the exact same impact if it's the final word.
| otterpro wrote:
| 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.
| baobabKoodaa wrote:
| 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 wrote:
| This is spot on for 99% of companies out there.
| zelphirkalt wrote:
| 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 wrote:
| 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 wrote:
| I feel like the hand wave should be the default until
| actually asked then you can dive into specifics.
| chadash wrote:
| > 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 wrote:
| 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'.
| jamesgill wrote:
| 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).
| jmpeax wrote:
| > 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.
| blitz_skull wrote:
| 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.
| polishdude20 wrote:
| 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.
| Greenpants wrote:
| 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.
| al_be_back wrote:
| 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
| :)
| nicechianti wrote:
| [dead]
| paddw wrote:
| 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.
| Artgor wrote:
| In general I agree. But if this approach is applied for the same
| system many times in a row, it can cause technical debt.
| quickthrower2 wrote:
| 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 wrote:
| 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.
| quickthrower2 wrote:
| As a welder, people pay YOU to weld. That is what solve their
| immediate problem.
|
| Sure end consumers buy, "their lost childhood" "the feeling
| of belonging" and "being a superhero" projected onto various
| objects of desire.
|
| But people can think logically too! I need a sparky. Yes
| because I am addicted to twitter, and have no bush survival
| skills either.
| BSEdlMMldESB wrote:
| 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
| jslatinsky wrote:
| [dead]
| yobbo wrote:
| > 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.
| swznd wrote:
| It's about triggering emotions, because most people buy with
| their emotions, word "thousands" make it feels a lot.
| chrisco255 wrote:
| "1000 songs in your pocket" is not a spec. It was a selling
| point. Songs, of course, are variable length things, so it's a
| marketing statement, not a spec. At the time the only way to
| get this many songs in your pocket was with massive pockets to
| hold a MP3 CD jewel case. Jobs didn't just build a faster horse
| when it came to the iPod. It was engineered purposefully to
| satisfy that desire.
| neilv wrote:
| > > _They told their customers: "1000 Songs in Your Pocket"._
|
| > _That is talking about specs, and it is exactly what the
| competition did too._
|
| Good catch. I'd expect something more in the direction of: "All
| your music. Always with you."
|
| (And when you buy much more music for this product, Apple can
| sell you the "All" solution again next year, in the form of an
| upgraded-specs model.)
| [deleted]
| giantrobot wrote:
| > That is talking about specs, and it is exactly what the
| competition did too. Here in the unit "number of songs".
|
| The statement isn't just the storage space in a convenient unit
| but also the approximate dimensions and weight in a convenient
| unit. But both parts of the statement are describing the
| problem being solved.
|
| It's a good marketing statement because it focuses on a problem
| being solved rather than the mechanism by which the problem is
| being solved. The iPod had a lot of clever engineering but the
| marketing was always about the "problem" of carrying music with
| you and the iPod solving that problem.
| finnh wrote:
| And I really, really doubt that competing mp3 players talked
| about "Mega Hertz", as this article's GPT-esque strawman puts
| it.
|
| Maybe they talked about "Giga Bytes", but I lived through that
| era and my recollection is that most stats for the mass market
| were, very simply: number of songs.
| scarface_74 wrote:
| > 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 wrote:
| > It in fact had less space than the Nomad and was kind of
| lame
|
| Rob Malda, is that you?
| stonemetal12 wrote:
| 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 wrote:
| I can't blame you for not getting the reference. It is over
| 20 years old now.
|
| https://m.slashdot.org/story/21026
| 1-more wrote:
| 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.
| gorpomon wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| tristor wrote:
| Speaking as a PM and a former Eng, if you could get 1.5x your
| features at this trade-off, the topline revenue that those
| features drive could very likely result in significant
| additional resources to provide to dev. I realize you can chase
| your tail with tech debt, but you're calling this "alright"
| code, not horrible code. I'd take that trade-off in either role
| I had.
| Apes wrote:
| 1.5x the features, 3x the code would roughly result in 1/3
| development velocity, 3x bugs, and 3x incidents going
| forward.
|
| Even assuming all your developers are magically given a solid
| understanding of the new code, all remaining velocity will be
| entirely consumed by bugs and incidents. No more feature
| development will occur.
|
| You could try to grow to outrun the code debt you've just
| acquired - but that's what literally every start up tries to
| do, and less than 10% succeed.
|
| The most likely outcome is that the company would enjoy a
| one-time massive feature feast before slowly dying over the
| course of 5-10 years or so.
|
| Great if you're a founder looking for a quick exit or some
| other position that is super focused on short term growth, I
| suppose.
| etblg wrote:
| > significant additional resources to provide to dev.
|
| Ah sweet, even more problems to deal with then. More people
| to onboard to support you in writing the 3x more code, more
| managers needed, or more strain on the managers, etc. We'll
| just fix it by hiring even more people.
| commandlinefan wrote:
| > more problems to deal with
|
| But that's not _his_ problem, and he already got his bonus
| for "hitting the date".
| tristor wrote:
| > Ah sweet, even more problems to deal with then.
|
| Whether or not adding more people is a problem greatly
| depends on the existing workload and where in the
| development cycle those folks are added. It also depends on
| the quality of the people. My comment was certainly not
| advocating for putting more meat into the grinder in favor
| of chasing the mythical man month.
|
| My point was more that if you can magic your way into 1.5x
| the features for 3x the code, and it's "alright", you can
| probably add 1.5x to the top-line revenue over the same
| time frame. A 1.5x increase in top line revenue, especially
| at a larger organization, is absolutely massive and opens
| up many possibilities, including hiring significant
| additional headcount. The headcount comes in /after/ this
| magical moment, not prior to or in the midst of. And yes,
| if you have 3x more code, you'd probably want more people
| to help manage resolving technical debt, fixing bugs, and
| generally dealing with the ongoing keep-the-lights-on work
| that is inherent in that.
| HWR_14 wrote:
| I'm amazed that as a PM you think features linearly drive
| revenue. This has not been my experience.
| szundi wrote:
| Of course you can always run out of time and go bankrupt
| and these people could go to other companies to work on a
| probably even worse codebase. Also everyone lost years of
| their lives chasing the CEO into perfectness
| woleium wrote:
| Alright code is a step up for some projects I've seen, lol.
| szundi wrote:
| Exactly
| vsareto wrote:
| Our field's (lack of) training sucks at teaching good code
| though.
|
| Plus some styles have changed over the years. If we keep
| changing quickly, good code is just a fad.
| thayne wrote:
| Even if the code is the same quality as existing code, having
| 3x of it will slow down development considerably. And will
| probably make developers less happy with their jobs, and
| increase churn. And hiring more devs will initially slow down
| development even more.
| zer8k wrote:
| That's your PMness speaking.
|
| PMs never consider who will manage the code down the line.
| They never consider the implied difficulty multiplier because
| if you can't party poker it, you can't build it! That's what
| the agile ninjas say! Code that is "kinda bad but ok" will
| end up being the cause of a SEV0 eventually. This kind of
| tradeoff is made by management because the entire field of
| software engineering is a joke to them.
|
| There's a trade off to be made. But it isn't the one posited.
| Creating code that is manageable implies it's better than
| "kinda bad but ok" but not all the way to a magnum opus in
| software engineering.
|
| Leave decisions like these to the engineers. If management
| isn't willing to give "significant additional resources" to
| engineers they get what they pay for. Enjoy your extremely
| high turnover. Of course, it'll never be your fault. The
| engineers will also suffer the consequences. It would be nice
| to see even one PM eat shit for their terrible project
| management decisions done in the name of "agile".
| tristor wrote:
| This rant doesn't seem to address my comment, and seems to
| be an expression of your existing anti-PM bias.
| deepspace wrote:
| > Leave decisions like these to the engineers.
|
| Maybe for a 1.1x increase in features, but for 1.5x
| (provided the new features solve actual customer problems),
| I will choose the genie every time. /PM
| brightball wrote:
| One thing that you do get paid for is productivity, which has
| tradeoffs if you're not agonizing over maintainability that
| will eventually catch up to you.
| webnrrd2k wrote:
| I think that taking the bargain would depend on the project...
| If it was software for a product that was on the market and had
| a lot of competitors, then it's a good deal as it would allow
| you to get ahead of the competition. Or, say, it was a new
| market and the features allow you to establish a strong lead.
| I'd definitely take the deal and then set up a team to do a
| refactor/rewrite or something.
|
| If the deal was used on internal software that already did it's
| job relatively well, then it's probably not worth the long-term
| trade off.
|
| I think that your larger point still stands, that most business
| people don't care about software engineering issues, but just
| want features, or solutions to problems, or whatever.
| Negotiating those issues in a business can be tough.
| sbjs wrote:
| The second best code is the code that gets the job done.
|
| The best code is the code that also doesn't make it harder to
| continue to get the job done.
| broken_clock wrote:
| Doesn't this depend heavily on the scale of the company you're
| at?
|
| At Google taking this is a no-brainer since for a myriad of
| reasons, feature development is slow.
|
| At a 6-mo startup this much tech debt this early on might just
| kill it.
| tmpz22 wrote:
| The problem is tech debt blows up sometimes. Maybe a critical
| engineer quits. Maybe there's a big outage. Maybe a big client
| churns because they've run into one too many points of
| friction.
|
| There absolutely is a time and place to ship "good enough
| code". But we have to factor in that for every ounce of credit
| a dev gets for shipping early there is three ounces of blame
| for when it goes way wrong.
| thfuran wrote:
| For most anything but a very new project, 1.5x the features
| isn't just advancing the roadmap, it's hitting the end and not
| stopping. At work, that'd probably be something like five years
| of work poofed into existence. Getting that for free is
| absolutely worth a fairly large amount of mediocre code.
| [deleted]
| justincredible wrote:
| [dead]
| yowlingcat wrote:
| I have found it's more practical to invert this train of
| thought and work backwards. In most codebases I've worked in,
| there are fairly clear divisions of labor between vanilla line
| of business code and critical path code that merits extra
| infrastructural investment.
|
| Working backwards from the critical path code to reinforce it
| with the infrastructure it needs to support robustness and ease
| of maintainability is valuable because it makes the path to ROI
| for the business very clear, and candidly, there is often lots
| of code that just wouldn't be high ROI to reinforce too much.
| notShabu wrote:
| as a counterpoint, this is sorta similar to how Apple creates
| products:
|
| there's quote about magic:
|
| > Sometimes magic is just someone spending more time on
| something than anyone else might reasonably expect. - Teller
|
| The 3x code is all the magical "stuff" and that goes on in the
| background to create the illusion of something magical just
| working as well as non-essential "flourishes" like animation of
| different font support
|
| However the key difference is that one magical feature is worth
| more than 1.5x a list of features to sell to various customers
| who only care about a different subset of those features.
|
| In both cases though, it's understood that there is an
| additional burden of complexity and upkeep in order to achieve
| an end goal. Every line of code adds additional entropy to the
| system until it caps out based on whatever rate of entropy
| expulsion the culture can maintain.
|
| The diminishing return on additional lines of code may be an
| unavoidable part of large systems. So it always feels like
| returning to the "Beginning" via a new project or new startup
| increase agency and leverage. Which is then perceived by
| marketing/sales/etc... as a constant refusal to move into the
| "future" b/c of "bad code danger".
| teaearlgraycold wrote:
| The code needs to work, but given that the actual writing of
| code is not most of the work to be done I think it's worth the
| extra time in polishing the code. Like how Apple designs the
| internals of their products to look as good as the externals.
| Once you've spent billions on R&D for custom chips, PCB
| layouts, optimizing heat transfer, etc. you really owe it to
| your product to spend a couple million on the finer things.
|
| Likewise, there can be an attitude of "Who cares about the
| code? I met the needs of the feature" that some devs will have.
| I've spent many an hour reading others' code, re-reading my own
| code over and over to learn the subtle differences in
| readability, cleanliness and maintainability between
| approaches. I want others to have some craftsmanship when
| writing code if we're working together. That also means getting
| the little details right in the user-facing parts.
|
| Most importantly you need humility when it comes time to throw
| away the code you felt so good about. All code is trouble. The
| best code is no code. Don't let your well crafted code get in
| the way of deleting what needs to get deleted.
| awkward wrote:
| Reading this, I am absolutely sure that several of my former
| employers have done a little djinn based outsourcing.
| Justsignedup wrote:
| I think about it in stages. What do we need more? To get shit
| done or to maintain. Great code helps with maintenance. Shit
| code can help ship fast.
|
| Your goal is to decide when to go from ship to maintain. And
| what level of quality should be the base level regardless.
| m_0x wrote:
| You're stating
|
| > you're not really paid for agonizing over eloquent or great
| code, but just code that "gets the job done".
|
| Somebody might interpret this statement as if nobody (in their
| context) should worry about writing good code. If you're
| writing good or bad code it doesn't matter as long as it works.
| Package and ship it and call it a day.
|
| But the author addresses this:
|
| > It's not even about good work. This is also a given. That's
| the default expectation, it's part of the package. The cake
| will be good.
|
| Then I'd say that you're paid for "good code that gets the job
| done".
| smallstepforman wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| ghoshbishakh wrote:
| A typo: "well enought" -> "well enough"
| Jarmsy wrote:
| 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.
| srazzaque wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2023-08-14 23:02 UTC)