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.
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.
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".
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
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.
> 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.
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.
It greatly depends on what the "features" are. We're being intentionally very hand-wavy here. If you are adding features that are incremental for existing customer markets, then of course it's not going to drive linear revenue (it may not even drive /any/ additional revenue), but if those features open up new markets and use cases it can grow revenue beyond linear for effort. It all depends, and we're not being specific enough to say one way or the other since this is a contrived hypothetical with vague inputs.
Engineering output doesn't even scale close to linearly, though. You _might_ grow revenue 1.5x but now you have 3x as much code/system and need 6-9x as the engineering headcount.
We probably just took a nice small/medium profitable business and completely fucked it.
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
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.
If I had a dollar for every time a SWE was promised “resources” to address tech debt I could probably retire. If you’re “not that PM”, good on you, but any seasoned SWE hears “we’ll address the tech debt {in the future}” and either laughs or cries on the inside.
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.
That's generously assuming that the executives will accept stopping of adding new features. Even more generous assumption is that they will give engineering time and space to grasp the new code and make it more maintainable.
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.
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.
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.
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.
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.
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".
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.
Thanks for positing this thought exercise. You kept me thinking on it all week! I reworded the hypothetical slightly to avoid magical loophole thinking and posed it to my team but they assumed I was being a trickster anyway. I posted some of my thoughts on it here: https://niedzielski.com/log/2023-08-20.
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.
Knowing what quality of code to ship when is part of the craft. This skill applies to a lot of professions. No carpenter puts the same detail into framing that they do into stain grade trim. Nor will they go furniture grade fasternerless install in a cheap tract home.
This isn't a revolutionary idea, but for some reason, software devs suffer from an excess of black and white thinking. Things must always be done a particular way. It's such a bad tick, we have created a host of tools that try to enforce as much rigid uniformity as we can manager to automate.
> 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".
>Somebody might interpret this statement as if nobody (in their context) should worry about writing good code.
The comment you quoted refers to great/eloquent code. But you took it to mean something different.
Given the rehashing of these same memes in dev communities since the dawn of programming, I don't believe there is a strong agreement on what "good code" even means practically speaking, even though we mostly agree on abstract principles.
IMHO, I think there is an understandable hesitation among developers to accepting that they're doing 'job for hire' work, instead aligning more with the idea that they're put in charge to produce something "beautiful".
Ultimately, it's all messy machine code with goto's and jumps everywhere and "elegant" data structures turning into bits mashed together in memory. The comments, naming conventions, coding formats, etc are all long gone.
This is in stark contrast when producing something physical where the finer engineering aspects shine through in the final product.
People are taking this comment literally and ignoring the spirit of it e.g. “for 1.5x I would but not 1.1x”… okay fine, what about 1.2x? The number doesn’t matter… the point is that SWEs care about code quality more than PMs and other non-devs ever will.
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.
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.
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 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.
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.)
> 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.
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'.
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.
maybe a better anology would be using the wrong tool to get something done. like you could use a high quality hammer to hammer a high quality screw into two pieces of wood, and it would probably hold them together, but you shouldn't.
you could build an entire SPA in pure JavaScript...
> 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.
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.
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.
"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.
> 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.
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.
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.
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.
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.
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.
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.
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.
I meant to imply that mp3 players were too expensive "at the time", compared to a cd player.
I was not saying other mp3 players were more expensive than ipods. I could have been more clear there. Mp3 Players were more expensive than CD Players thus adoption was slow in the beginning, but the popularity of the ipod changed the mindset surrounding digital media players in general.
Once the ipod exploded in popularity many more mp3 players were sold to those who couldn't afford apple prices.
The previous poster was saying that EVERY kid had an mp3 player before ipods blew up where the opposite is true.
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.)
> 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.
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?
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.
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"
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.
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.
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”
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.
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.
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.
> 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.
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.
> 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.
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.
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.
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.
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.
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.
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!)
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)
Only if you use dictionary meanings of words. Otherwise it really is not different. 99.99% of all meaningful code is not gotten right on the first try. As said above, you have to iterate on it.
> I'm referring to the fact that code can be made into libraries, or APIs if you're so keen on collecting rent
Name one library -- that is NOT just a network client for a paid SaaS service -- and then maybe I'll understand what point you're trying to make. And even if you find one, they are a vanishingly small, undetectable, minority.
you should learn about systems software... they may be 'vanishingly small' but they're there in the foundations of the entire computing stack. done once, a long time ago, and used by all ever since.
my point is that I refuse to adjust my expectations to a technological environment in which we are ok with having to pay per API call to use software.
I reject a future in which all software works as a subscription based service; this is just more taxes (in principle)
I see society going down this path and there are no good reasons for this at all (it is just double then triple then mutliplefold taxation on activity; and what for? so that few lucky persons collect rent forever?).
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.
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.
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".
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.
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.
> 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
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."
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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."
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.
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.
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).
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.
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.
> 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.
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.
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.
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.
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.
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.
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 :)
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.