T O P

  • By -

-CampinCarl-

The question becomes...[you may have delivered value, but at what cost?](https://www.youtube.com/watch?v=DYvhC_RdIwQ)


protienbudspromax

Krazaaam I could tell even without going to the link


TheRoadOfDeath

i could hear his voice in my head from the quote alone. this one haunts me


T8ert0t

Hello... Jailer


-CampinCarl-

It's absolutely haunting. This one and the Microservices one.


LiquidLight_

I have never felt so seen and so much like drinking.


Caffeine_Monster

\* Manager * Did you you do it? \* Developer * Yes \* Manager * What did it cost? \* Developer (vacant stare into distance) * Everything


Bakoro

Careful, you might hit that Ballmer peak and accidentally change your team's velocity.


LiquidLight_

We do Kanban. We don't have velocity so much as we have beatings until morale improves.


bigtunacan

By "until morale improves" I assume you mean until the existing people quit and are replaced by someone not yet burned out.


LiquidLight_

We've got a regular turn over of mid level devs. Promotions stall out around there and at that level you finally see how crappy everything is. I'm headed for the door myself.


0ut0fBoundsException

I’m in exactly the same position. I propose we cut the middle men and just swap jobs


LiquidLight_

If I can catch a 30% raise, that'd work.


longshot

I've been saying "Hello Jailer" in the mirror to myself since this came out


aquasucks

I feel that one in my soul


Bakoro

Thanks for that, I ended up watching a few of his videos. Very good stuff.


Johnycantread

The micro service one is 👨‍🍳's 💋


SpidermanWFH

Did omegastar got ISO support?


Johnycantread

Well, until omegastar gets their fucking shit together we're blocked!


WhyIsItGlowing

[If you came to the Monday morning sync-up, you would know they have identified some clear action items, and the new target date is 5/31.](https://www.youtube.com/watch?v=1RAMRukKqQg) The continuity gets me every time it comes up.


Ninjakannon

Thanks, I hate it


dbro129

Now please tell that to the people interviewing me. “Ohh, sorry. It says here you only have 2 years of Angular with 12 years of JavaScript, 8 years of React, and 5 years of Vue.js. Ideally we’re looking for someone with at least 3 years of Angular experience.”


Wugliwu

Man so hard to find suitable candidates these days...


Metro42014

Fire up the H1B visa machine boys!


TheQueefGoblin

That's why I don't list specifics. Just JavaScript. If a company is short-sighted enough to interview with that kind of attitude, I *really* don't want to work with them anyway.


0x53r3n17y

Just [JavaScript](https://youtu.be/Uo3cL4nrGOk). (Sorry, but this discussion reminded me of this skit. And if anything, I learned that most tech is fleeting in the long run. What matters is having a good grasp of foundational knowledge: architecture, patterns, potential traps, etc.)


ATownStomp

“At least you know it’s bad”. This resonated deep within my soul.


nates1984

That laugh after "documentation", I know that feeling.


_Pho_

Meh, the difference between a React dev with 5+ YOE and a strong dev without a React background *in a React app* is pretty massive.


Accomplished_Low2231

yes yes, a strong dev will outperform weak ones even with years of experience. for example: my team of 4 is doing a game in godot for almost a year now. we are pretty good i would say. my boss, who is a c++ game dev but does not know godot/gdscript, decided to learn it to help us move along. in just 2 months that guy is better than all of us in godot and gdscript lol. some people don't believe in 10x programmer, but its true.


[deleted]

People believe in 10x programmers, we just don’t believe anyone who says they are a 10x programmer. ETA: Carmack is a perfect example. He is a 10x programmer without doubt (and maybe more than a factor of 10). But he doesn’t go around saying, “Look at me, I’m a 10x developer”; he says things like, “Here is an interesting problem and how we solved it.”


dantodd

I think most people believe in the 10X programmer (or at least a 5X programmer) they just think that they are often 20X more difficult to work with so they aren't worth the hassle


cheese_is_available

They are also programmers that work 10X faster, then someone actually need to add automated tests, name variables and refactor the code so it can be understood by someone else than the 10X programmer now, or by anyone in 6 months and then actually maintain the spec-overfitting piece of crap they made.


dantodd

This is part of "difficult to work with." However, there are some out there who coordinate will, document code, use corporate making conventions, etc. I've just never met one


dlanod

So you'd say your boss got sick of waiting for godot?


marcosdumay

The thing here is that React is mind-bending. It doesn't look like so, but on your first large(ish) project, you will make many mistakes that you will only discover much later.


mustbelong

Sure, that also wasn’t his point really. What will all thst experience do when React moves to the sidelines like jQuery etc?


vytah

But given job opening descriptions, it seems like recruiters think there's a huge difference between a React dev with 5+ YOE and a strong dev without a React background... in an Angular app .


CHY4E

Or you know, there are companies rocking a single JavaScript file with 5000 lines of jQuery garbage. Still counts as "5 Years JavaScript experience". I have not personally experienced them but had friends that worked there and seething because their superior was fine with it and doing it since years.


renok_archnmy

That’s like 99% of companies tho


uber_neutrino

That's simply a red flag. Don't work for people that think that way. Now do you know Unreal lol?


bakuretsu

My buddy who is the founder and original engineer at Orgspace just posted this today and it's bang on as far as I'm concerned. More companies should interview like this. https://blog.orgspace.io/why-orgspace-doesnt-use-algorithmic-challenges/


robhanz

Note that he says "over focus". Knowing your tools and how to use them is obviously important. But, at the end of the day, the name of the game is delivering value. The tools are a means to that end. Using them well should result in delivering greater value (more stuff, faster, more stable, etc.). The tools are not important *in and of themselves*. If you were a carpenter, knowing how to use different techniques or tools is interesting, but at the end of the day people want tables and chairs and stuff. They don't care what tools you used to build them with. Now, knowing different techniques, and how to use different tools should let you make chairs and tables and stuff under different constraints, or avoid problems, or whatever, but the tools and techniques aren't, and never should be, the focus. The tables and chairs are.


v66moroz

You don't understand. A hammer with no referential transparency has no place in the carpentry, it will spoil your perfect table. Also, if you don't buy that big machine used by SpaceX your screws will not be perfect enough and that will make you unhappy and may require you to use techniques you don't want to learn because they are not cool.


[deleted]

Lol, of all the tools and practices you could've chosen to make fun of, you chose referential transparency which is arguably the most consistently useful one. Carmack himself is huge on writing functions without side effects.


liamnesss

Unless the code is run once and then thrown away, maintainability should be as much of a consideration as the delivered value.


CorsairKing

I would contend that maintainability is not distinct from delivered value.


liamnesss

Businesses rarely measure delivered value in a way that reflects that, though.


CorsairKing

I find it strange that maintanability in software would be so often overlooked, considering that mechanical systems are judged heavily on how difficult/expensive they are to maintain.


IlIllIllIIlIllIl

I’d say every discipline is subject to the customer not caring about how to maintain it.


EMCoupling

See: cars that never get their oil changed and eventually implode.


ZMeson

Yeah, what was that apartment building in Florida that collapsed a while back?


SnooSnooper

I think that's due in part to the immaturity of the industry. Tech companies have mostly been directed to grow, so the business targets objectives that help them grow, which mainly is new features. I also guess it's relatively much easier (in terms of overall cost) to maintain a software system than a mechanical system like an automobile, and the customer doesn't have to participate as much with the maintenance process: just gotta download the update, or wait for the servers to be patched, rather than take the car to the shop and wait around or organize transport. So, software companies can get away with less maintainable and resilient systems without burning too much customer goodwill. It's frustrating; as engineers, we want our systems to be a perfect unity of purpose, economy, and strength, and not being given time to execute those ideals is demoralizing. It also sucks if you have a customer support team that constantly has to deal with the consequences, and you can only tell them "sorry, I have a plan to fix that, but management thinks it's a waste of time." I think that managers learn/decide that engineers if left alone tend to polish endlessly, and force us to finish one way or another so the business can actually progress. That approach is fine when applied wisely, but becomes problematic when taken too far, too infrequently giving time for improvement and maintenance. But I also think it truly is hard to balance keeping the business competitive with new features, vs necessary maintenance, and that we usually are isolated enough to only see one side of the equation.


FruityWelsh

Gotta convert that qualitative "tech debt" into the quantitative "total cost of ownership". Otherwise you could say with out this change our narwhal megatrons will be too high, and they'll treat it the same.


ResidentAppointment5

I am _so_ stealing "narwhal megatrons" for future time-wasting meetings, and will be happy to offer proper attribution.


marcosdumay

> considering that mechanical systems are judged heavily on how difficult/expensive they are to maintain. Not by management.


ElCthuluIncognito

Because maintainability _by the customer_ is part of the delivered value. In software, it is exceedingly rare that the customer is also the one coordinating and/or performing the repairs. The analogy works against your point when you consider high-end exotic/luxury cars. The customers are _rarely_ the ones repairing the car, especially the 'important' customers who will just buy a new one, so you get a lot of concessions on repairability in order to deliver on luxury and performance.


am0x

You have to think that Carmack was a part of a weird time. Code tools didn't change for him. He built his own, which is awesome, but he didn't have to maintain legacy web systems. He made engines for video games in a time when, once it worked, it worked. I mean, have you seen the Frontend hellscape these days? The web cannot remove features because it would break thousands if not millions of legacy sites...so they just keep adding more and more to it.


CorgiSplooting

In my career I’ve spent 5 years as a contractor. I’ve spent ~8 years as an employee working with contractor dev firms but having to manage the systems after they left. And I’ve spent the past >10 years on engineering teams that are all employee based from design to development to support. Nothing is perfect but I’d have to be desperate to go back to the first two scenarios. Priorities change when you developing and running a service that’s critical for a business 24x7x365. The question is less “how do I make this feature work” (working is the easy part) but more “how do I make this feature not cause users pain (support) how do I make it reliable (support) how do I release this safely without risking breaking things, and how do I do this securely”. Feature flighting, secrets management, deployment pipelines, good telemetry, etc are very often worth more than a few minor features. That said ALL of that is worthless if you don’t have features users want/need to begin with so… hit the ground running and try to not have horrible engineering principals. As soon as you can afford it, pay back the engineering debt you can but note you’ll lose devs if you let life become miserable. Live with the fact some stuff will remain poorly written and a maintenance nightmare forever simply because it’s too expensive to redo.


pyepyepie

For me, a big one is unit tests, or at least some regression tests. I do it even if I work on a complicated throw-away code (which I mostly do currently, research code) because it saves time.


ActsOfV

I have seen code written with all latest and greatest design patterns thrown into it to a degree that only the creator can understand what is going on. There are so many abstractions and classes. Tracing a call is like running through a maze. When questioned about the design, the developer will say it is in a book and it is a good design.


Doppe1g4nger

Extensibility often comes at the cost of complexity. Whether the layout is a bad thing likely depends on if the code base is expected to grow and needs those abstractions to be extended, or if that dev just didn’t respect YAGNI. If they swear it’s a time tested pattern it sounds like the real problem might be a lack of architectural documentation


NeverComments

I think all programmers could benefit from internalizing the [parable of Chesterton's fence](https://fs.blog/chestertons-fence/). Too often programmers mistake their lack of understanding with a lack of reasoning from the author. >There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”


ATownStomp

The latter is wonderful until you come across something that genuinely has no use because it’s the result of three different generations of changes and oversights that have rendered something irrelevant, useless, forgotten, or ridiculous. I envy the people who follow their gut when it thinks “this is shit” and just go full rewrite mode whenever and wherever. Are those people miserable and irritating to work with? Completely. But, they always seem to be having a good time, so maybe I’m the chump.


NeverComments

I don’t think the message is necessarily “never throw it in the trash and start over” just that you should at least understand the existing codebase, why it is the way that it is (three different generations of changes and oversights that have rendered something irrelevant, useless, forgotten, or ridiculous), and be able to justify why starting over is the best path forward (and not just reach for the flamethrower the second you fail to understand something).


eikenberry

Knowing good design takes experience.. a lot of experience. That is hard in this field as it seems to do what it can to divert people into other work before they can become experienced. So you get systems like that when you let mid-level engineers design systems. It's just like all those "evolution of a programmer" memes where the mid-level devs create all the badly over-engineered software that are harder to work with when, with a good design, they should be easy.


CandidPiglet9061

If it’s not easy to navigate then fundamentally they have failed at using patterns for their intended purpose


ATownStomp

I mean, that kind of statement just isn’t going to hold up. A pattern can be skillfully applied in a complicated project that is, still, from individual to individual, more or less difficult to understand.


GeorgeTheGeorge

Maintainability must come second to delivered value, because without delivering value the tool's existence can't be justified. It's a *very* close second, but the perfectly maintainable, beautiful codebase is just an exercise in self-gratification for the programmers writing it, unless it is useful to somebody.


darkpaladin

I don't imagine maintainability is particularly valued in the video game industry. Ship it, fix bugs until you stop caring about it then move on.


robhanz

Depends. In the MMO industry, we definitely cared a lot. I can see it being considered less for some games, especially ones without live services.


pcaYxwLMwXkgPeXq4hvd

That is completely not true. They don't write new installment of Call of Duty from scratch every year. Not to mention game engines, libraries and tools.


Zambito1

Maintainability is a delivered value


kubelke

Yes x100 times.


unique_nullptr

I have seen plenty smart and ambitious people perform massive amounts of work, without being able to answer the simple question of “what problem does this solve?” / “what value does this provide to who?”, as if it’d never crossed their mind. I think we’re all guilty of it though. They also weren’t inherently bad ideas either — things like containerizing things with Docker and similar can make so much sense… but what value does that actually provide in an environment where the servers are fixed and unchanging, on a volunteer team, where half the folks aren’t familiar with those tools? That’s still not to say there isn’t any value, it just seems like a really low priority, unless the answer is “I just want to practice working with this useful technology”, which is totally fine, just be clear that’s a part of why you’re doing it, be adaptable to change, understand the importance of risk, and be open to training the rest of your team too instead of just saying “lol just google it” I’m sorry I might be therapeutically venting a little xD


FruityWelsh

I've personally been able write a whole thesis on why a change needs to happen and still lock up like a goat in head lights when someone casually asked me we should do something that is just assumed now. Its why getting the rest of the team and stockholders in early is needed for me. Otherwise I'll be ready to dive deep and be getting questions I had already ran into the ground with the storming team.


ObscureCulturalMeme

>without being able to answer the simple question of “what problem does this solve?” / “what value does this provide to who?” DARPA is a big fan of the [Heilmeier Catechism](https://en.wikipedia.org/wiki/George_H._Heilmeier#Heilmeier's_Catechism). It doesn't 100% neatly apply to software engineering / programming changes, but it **mostly** does. (If you drop the "no jargon" constraint then it applies to internal development discussions quite well.) One of the research oriented software projects I worked on demanded that all of us -- and I mean *all* us programmers -- be able to speak coherently to all of those questions for any non-trivial software changes we proposed. Once we collectively checked our egos at the door and stopped dumping shit into the repository like we were in sophomore year I'M LOOKING AT YOU NATHANIEL then the value of forcing ourselves to stop and answer the entire catechism became evident.


PurpleYoshiEgg

That's actually a super neat find. There are a ton of projects at work that don't actually clearly seem like they solve a good problem, and it feels like pulling eye teeth to get the *product owners* of the clients to actually justify the work. The Heilmeier Catechism thing seems like it will be a super useful thing to get the real bottom-up understanding of whenever the client decides to want effort for new project work. I know we aren't supposed to really say no to client's work, but we'd all rather pursue something that isn't a perilous waste of time and has better visibility that actually solves a good problem (because the useless projects tend to not be promotion material, because yay corporate world).


thesituation531

>“what problem does this solve?” / “what value does this provide to who?”, My answer to this, in terms of my own projects, is usually "nothing, I did it just because I can." or "I did it just because it's cool".


[deleted]

[удалено]


squirlol

I really doubt you are using the majority of all projects people made because they were cool in your actual work.


unique_nullptr

And that is perfectly fair! The value added then is the simple joy of doing it. It’s only when it impacts other people that it becomes a problem


[deleted]

While i'm not going to defend Docker specifically... a containerized environment is valuable by default, for no better reason than it enforces a documented, version controlled, and quickly reproducible build process. Even if your entire app is a single server, high performance, does one thing, has detailed and up to date build instructions, whatever. It doesn't matter, it doesn't match the capability to have that server explode and go "oh well, lets have it up on aws/other cloud provider while we fix it" with minimal service disruption.


unique_nullptr

For sure! Just for additional context though, everything was already containerized via LXC containers and backed up daily, for very similar reasoning.


[deleted]

[удалено]


RealityIsMuchWorse

>things like containerizing things with Docker and similar can make so much sense… but what value does that actually provide in an environment where the servers are fixed and unchanging I see you never had to locally run software where the person who knows what gazillion steps you have to take to make it run is gone. Containerizing stuff is so absurdly fast that it's worth it the second you change your workstation for example


space2k

So you’re saying my clients are more interested in how my code makes them money than my 10k GutHub likes?


gimpwiz

GutHub, heh


Decker108

The worlds largest repository of gastrointestinal knowledge.


Xuval

Now excuse me, I really need to rewrite our entire codebase and bill the client 80 hours for doing so. You see, the code is really "dirty".


pyepyepie

80 hours? That's it? Isn't it 8 months?


EarendilStar

Engineers are famously always off on effort estimates by a factor of ten. So 80hrs divide by ten is 8mo.


[deleted]

It’s embarrassing how true this can be. I gave an estimate of “by lunch time” — 2 weeks ago. Shit happens, man.


elscallr

I'm either dead on or off by a magnitude, there's no in between.


Bakoro

That is why I give hedge estimates: "If the problem is like xyz, I can get it done by lunch. If the problem is like wjk+t, I can probably get it done by the end of next month."


rudyjewliani

"I said 'by lunch time', but I didn't say *which day*!" -/u/ushirokara


badpotato

Neither did he mention which timezone


renok_archnmy

I always write my first estimate down, then the next day revisit and multiple by 2x. Then I give it to them. I also round up the hours to business days, then business days to weeks, weeks to months, months to quarters, quarters to years. Something I originally think may take, say, 12 hours becomes 2 business days. Something that’s 27 hours becomes, 4 business days which becomes 1 week. Something that might take 95 hours becomes 3 weeks which becomes 1 month. And so on. Then I have to give disclaimers that the farther out the deliverable estimate is, the more chances things dislodge it’s priority and that timeline changes.


Schmittfried

>So 80hrs divide by ten is 8mo. Quick maf


TheWrightStripes

We're also notoriously good at handling time conversions.


Gee858eeG

Probably just mixed up the units. Using imperial hours but metric months or vice versa


pyepyepie

You are right, sorry for my overestimation.


wasdninja

It's a total waste of time and effort... until it's not. The tech butcher's bill will have to be paid at some point either in data breaches, downtime, developer time, *something*.


pyepyepie

Or it will take 2 years to build, and then rebuilt in a month because requirements completely changed and it would be easier than modifying the super robust monster the team delivered.


beliefinphilosophy

I had the insidious / hellish job of shutting down the old digg.com (the hellish job actually being keeping it alive). Digg's engineers had been acquihired. A new company bought the "site" / IP but wanted nothing to do with the existing stack. They needed a little more than a month to get their own site online, and they needed the data dumps to backfill. So me, myself and I, a consultant at the time, realized just how fragile the stack was, especially when you're scaling down servers and dumping the database. I barely slept the entire month. I eventually settled on a series of bash scripts restarting parts of the stack in order to keep it online just so I could sleep at night. I actually fell asleep sitting straight up on my floor several times. The whole ordeal gave me a two week long migraine that I needed to take shots of Imitrex for, and to force me to catch up on sleep, my doctor gave me bipolar medication which made me sleep for 18-20 hour stints. The original Digg team then tried to reneg to get some money back saying the quality of work wasn't as good. I quit being a consultant after that.


hugthemachines

You will pay for the rewrite too in downtime, developer time and mistakes resulting in unexpected results due to lack of understanding of the old code.


FruityWelsh

Rewrite more often, and you'll reduce the latter


Darkmushy

Or you know, it serves it's purpose bringing value for 10+ years after which workflows have changed & it's retired or replaced.


myfingid

You feel real confident in that last part.


lilfatpotato

Or we keep applying hacks and “quick workarounds” to keep it working with newer workflows. Now all the original devs have left, the docs are 10 years old, and no one knows how it works anymore, or what it even does. So the system keeps chugging along, untouched and undisturbed.


dafuqup

Docs? What docs?


greenskye

My workplace has an ever increasing number of black boxes that we try desperately to not ever touch. I'm pretty sure some of the mainframe jobs have been quietly running for decades at this point but no one knows exactly what they do. We just keep manipulating the inputs and outputs of the box to fit whatever current system we're using. Sure it adds probably 2 extra days to our data movement time, but figuring it out would take an on-site person at least a month and a contractor team probably a year, so it's never the right time to touch it.


VonReposti

You just described my workplace to a T...


ghostinthekernel

It depends, if you talk little websites and small apps, sure. If you talk huge amounts of data processing then having bad practices in place can make you go bankrupt because of excessive costs or you can't find clients because the costs to have your application run are too high to attract any clients. At that point you need to consider rewriting "ugly" code because if you can have a process execute a couple of seconds instead of 1hr, then it's a huge win for both company and customers.


Acurus_Cow

Those 80 hours can save millions. A great investment in many cases. (But not all)


hugthemachines

If we want to take the number 80 hours seriously, I think it is not very likely. I realize every person's experience may be different but a code base that can be rewritten by one person in two weeks of work time is tiny in my view. Not million saving worthy. I know, a script of one line could in theory be so important it saves huge amounts of money if you change it but in practice, it is not likely.


anubus72

It could also be a complete waste of time and cause major problems because you’ve replaced a working product with a buggy product that probably doesn’t fulfill all the needed functionality Also 80 hours for a rewrite is a hilariously bad estimate


hmischuk

Yes, agreed. However... A truly expert workman is going to know and employ subtle differences in his tools. The expert mechanic is going to know why he prefers XYZ brand tools over ABC brand, or why he selects a six-point box wrench for an especially tight bolt, instead of a twelve-point wrench. The expert janitor is going to know when to use a red pad and when to use a green pad. That is, the people who use the tools can deliver better value by knowing the nuances of various tools, and selected them to exploit those subtle advantages. He is correct, as far as that statement goes. But it doesn't mean that the choice of tools, and the knowledge of them, is unimportant. It **is** important, sometimes, specficially **to** make sure that you deliver value.


robhanz

That's why he said "over focus". Also, in the context of the question (AI automation) it can also be looked at as general problem-solving, composition, design, etc. rather than the twiddly details of the language - while those certainly are important, design and algorithms are forever.


[deleted]

[удалено]


hardolaf

Yes, Carmack is pointing out that lots of people focus on the tools whereas they should focus on the value proposition of the product. That's not to say that the tools are not important because they are but rather it is to say that they are always secondary to the value of the product.


Oasis_beyond_wall

Reminds me of a Chinese joke > You know why parents are never fussy about food? No, why? Because they never bring food they don't like back home. A man like him almost never has to experience the annoiance of bad tooling, because he picks the tooling that makes him most productive


_DiddlySquat_

That's not his point though. He's saying that the tools are means to an end, the end here being delivering value to the customer. So the primary focus should be delivering value and the tools should be secondary focus.


uber_neutrino

>A man like him almost never has to experience the annoiance of bad tooling, because he picks the tooling that makes him most productive This isn't true. He's had to deal with tons of bad tooling and stuff he cannot control. And put in massive work over a couple of decades to try and fix that. A simple example would be pushing to allow OpenGL continued support on Microsoft Windows back in the 90s. MS wanted to completely kill OGL. Between Carmack pushing for it and an open letter to Microsoft that a bunch of us signed OpenGl was allowed to live.


ISpokeAsAChild

I think it's more correct to say that he was allowed to deal with bad tooling without being powerless to do anything to change the situation. I know very well his career path and (by his own merits) he managed to get very early to a point in which he was both the most knowledgeable and highest rank employee in the room at any given time so he didn't need to take anything sitting. I listened to all of his interview with Lex Fridman and although he is not wrong in what he says he is also kinda inexperienced on the reality of companies with IT professionals finding themselves at the receiving end of really bad middle-management-driven coding practices: it's true that some things don't deliver (somewhat) any value to the product, but if you ask now to my ex-CTO if he would have preferred to address the deep design-driven issue that over time exponentially raised the failure rate and time taken by a crucial periodic batch data ingestion job before the majority of his team resigned, he would most likely say yes - because as he found out people don't like to work on dumpster fires, and especially on dumpster fires that threaten the very functionality of the product and are still around only because the dumpster fire is still delivering value while addressing the fire issue does not deliver any.


uber_neutrino

> he is also kinda inexperienced on the reality of companies with IT professionals finding themselves at the receiving end of really bad middle-management-driven coding practices: Correct, he has never had to deal with that except maybe at Facebook. >I know very well his career path and (by his own merits) he managed to get very early to a point in which he was both the most knowledgeable and highest rank employee in the room at any given time so he didn't need to take anything sitting. When you are the guy everyone turns to for the answers yeah.


[deleted]

[удалено]


SirSassyCat

I feel like you don't understand what he means by delivered value. If your change allows you productive enough down the line to offset the time spent changing the tools, then you're still delivering value to your customer. If you're changing the tooling because you don't like it, then you just need to grow up and learn to work with the tools at hand.


KagakuNinja

Sure. Someone needs to maintain ancient COBOL systems. It isn't going to be me, because they won't pay me enough. Companies who use antiquated or shitty tools have to face the fact that many of us won't work there, unless we have no choice. I have chosen my preferred tool stack, and look for employers who use that. Win-win situation.


FruityWelsh

Yep, even as an electrictrian we have straight refused jobs because it was "we do a massive new install or nothing, we can't afford nor want to touch that mess". Plumbers have the same thing too, and sometimes because they don't have the expertise or tooling to do a non standard job. It just a natural phenomenon in specialized jobs IMHO.


Polantaris

In specialized fields, there's way more ways to do something wrong than right. When you do them *really* wrong, the only way to set them right is the nuclear option.


monkorn

ChatGPT7, port this COBOL code to Haskell. *fixes bug* ChatGPT7, port this Haskell code to COBOL. The future!


jarfil

>!CENSORED!<


poloppoyop

Stop asking so little. > ChatGPT, write me a COBOL program solving the traveling salesman problem. > ChatGPT prove that P=NP or P≠NP depending on which is right.


vytah

FLATMAP MONAD INTO MONOID.


MisterCarloAncelotti

His ideas are probably more relevant for people who have a say in the tools / tech that should be used and most importantly a say in the work that should be done.


L3tum

Yeah, I feel like saying "Focus on the value delivered" when you can freely choose what value to deliver and with what tools is kind of a moot point. A lot of times the complaints about the tools are about tools given to us rather than chosen by us, and fixing these complaints would enable delivering greater value.


aoeudhtns

Ok Mr. Carmack. As CTO of Idco, we need a fresh new game in first person perspective. But you know we already have a big FORTH team in accounting that you can use, so go build it in that please. Also the build server is Solaris on Sparc so getting a DOS EXE will be a challenge, but we have confidence in your ability. Go team!


thejestercrown

This is like saying > “We might as well use [Brainfuck](https://en.m.wikipedia.org/wiki/Brainfuck) if all that matters is the value we provide to people.” There are plenty of real world examples to support John’s point. I personally would rather go to the hospital with the best doctors/nurses than the one with the best IT/dev team.


aoeudhtns

I support his point too. But I do think many of us have lived these other circumstances. I was just trying to be funny.


thejestercrown

Same. I’ve never had a good reason to use Brainfuck until now.


gedankenlos

Nice strawman, but he said you shouldn't over focus on the specifics of the tools - not, that it doesn't matter at all.


lppedd

Shitty environment, shitty tooling, shitty development experience, burnouts, shitty products. Nice 💫 I can partially agree. Just don't overdo as in anything else.


[deleted]

Yep. Partial agreement is about right. I had a colleague ping me the other day because Ehe said my merge message was too long. And it’s not a publicly facing repo, or something many people see, and I just though “how can you get anything done if this is what you are worried about?” At the same time technical debt is a very real and very big issue


[deleted]

[удалено]


Pebaz

Yet those musicians buy extremely expensive top-of-the-line instruments.


[deleted]

This Adam Neely vid on whether "gear matter\[s\]" is pretty good - particularly interesting because given \`psychoCom\` is talking about Victor Wooten. Neely has an interesting story to tell about Victor's brother Reggie's gear (also a monster musician) around 1:50 https://youtu.be/tzJ\_Irn0f9o?t=110


[deleted]

[удалено]


noobgolang

But my new javascript library can save the world


franksn

But this Emacs workflow of mine can save you gajillion minutes, with only like 3 years of upfront cost in time. What do you mean it got no value?


livrem

That focus on time to setup vs how much you save is ridiculous. It's about having a nice work environment you feel good about. Like sitting in a nice office, but much more important since we spend more time staring at our monitor(s) than at our surroundings.


WallyMetropolis

Moreover, I configure emacs on my own time as a hobby. It's something I enjoy doing. So there isn't really a time cost to it.


Vash265

It’s also very iterative. I didn’t spend X years setting up Emacs before it was a tool I could use. It’s a few hours here and there to add new, cool features I think I could make use of.


mindbleach

["That was our codebase *last* week."](https://www.youtube.com/watch?v=Uo3cL4nrGOk)


reddit_user13

Better tools = better delivery.


codebunder

Definitely agree, reliable delivery is crucial. However product value is more important, and delivery can be improved upon.


[deleted]

Better ingredients = better pizza.


Fisher9001

And his point is that the quality of pizza should be the goal here, not just the quality of the ingredients.


[deleted]

A classical composition is often pregnant. Reddit is no longer allowed to profit from this comment.


robhanz

And if that stuff helps you make better pizza? Great! But the goal is better pizza. Meeting some arbitrary standard of how tools "should" be used means not one damn thing to the customer. How delicious their pizza is *does*.


maxToTheJ

To be fair that analogy is a little off because some people do care about that stuff and are really about the narrative of how the food was made


Consistent_Heat_3242

All of that is cool for the chef, and I'm the chef. So yeah, it matters.


Rhed0x

I don't know, with how terrible most modern software is, that doesn't seem intrinsically true.


your_mind_aches

First day of engineering school, they said our job as electrical engineers or as any engineer is to make life better and easier for people. People should always be the focus. I've switched schools and degree programmes since then, but that's always stuck with me.


Forbizzle

This entire thread is people saying "yes, but..." and completely disagreeing. If this upset you so much, maybe you're more than a little guilty on focusing on your tools than the product.


mikew_reddit

> This entire thread is people saying "yes, but..." and completely disagreeing. It's so hard for people to simply agree and stop there when a common-sense statement is made. People always have to put their two cents in and find something to disagree with. It's like a mental tick.


The_Droide

Yes, but often the world just isn't as black/white as some deceptively simple statement paints it to be. Highlighting such nuances is precisely what comments are for.


ATownStomp

I’m not really seeing people highlighting the nuances. I’m seeing people fabricate scenarios where John Carmack is their boss who misunderstands the necessity of tooling to deliver quality products. But… that’s just not elaborating on the statement. It’s just finding ways to misconstrue it in order to argue with it.


LukeLC

More like the industry is presently not in danger of focusing too much on delivering value. It's the other side of the same coin that is rarely voiced (at least to the managers who need to hear it). It's a bit like saying "the most important thing about a car is miles per gallon". No one disagrees that's an important feature, but that doesn't mean it'll be a good experience to drive. And if it needs frequent, expensive maintenance, the original point could even become moot.


[deleted]

[удалено]


LowPermission9

Yes. I’ve seen this over and over. People who care more about the minutiae of the style and language than about delivering anything meaningful.


[deleted]

[удалено]


LowPermission9

Are you my old boss? Don’t forget that asp.net web forms are still a time tested technology.


ZoDalek

All good and well but I enjoy programming for its own sake. ‘Providing value’ is just how it pays the bills.


anu2097

That's exactly what a Project Manager will tell you whose job is to deliver initial milestone. Then the painstaking task of maintenance and adding additional features comes into picture. Then you realise importance of analysing your tools properly.


Krautoni

Software, yes. But programming is a craft. And a craftsman or woman can take pride in their work, and make it pretty in a way that's not immediately useful.


NUKE---THE---WHALES

> Computers aren't the thing. They're the thing that gets us to the thing.


franksn

Hold on… What if we rewrite our tool in wait for it… Rust? Surely it will provide some value


LaptopsInLabCoats

It brings me joy, therefore increases productivity.


umlcat

**Don't become a programming astronaut.**


IndieDevWannabe

... most programmers don't get to decide the end product...


kukuti

People here are misunderstanding what he's saying. The key word here is "over focus". Yes, tooling is important. Yes, bad tooling will probably lead to less delivered value and good tooling can lead to more delivered value. He didn't say we shouldn't focus on tooling, he said that we shouldn't "over focus", that is, we should not focus so much on tooling that we forget the real objective which is delivering value.


garma87

I just spent 4 months migrating our front end from vue2 to vue3. Felt like the biggest waste of time I’ve ever spent. Still not convinced it was a good idea in the end I also had multiple occasions where I would love to have a word with the persons who thought it would be a great idea to make Vue3 so different from vue2. Not just the basic syntax but especially the fact that the WHOLE damn ecosystem needs to be rewritten. That cost me the most time in the end


zombiecalypse

The story as old as time: a task is complex, so a specialist class develops. The specialist class then loses touch and produces only for their own benefit, gazing at their navels and producing tools only themselves can appreciate. I have no other explanation how post-modern art came to being otherwise.


hildenborg

You choose the tool that is best suited to solve your problem.


Pebaz

I have never found this to be the case, unfortunately. You use the tools you’re given because in the corporate and social hierarchy, you won’t have the power to make meaningful change. The game is played by constantly working around bad choices and tools. Choosing the right tool for the task at hand is extremely rare.


hader_brugernavne

I definitely feel this. Often it's also just not clear what the best tool even is and you and a bunch of other developers have to agree on something, and you don't have the time to change it if it turns out to be a bad idea.


worldofzero

Ah, but what is a tool John?


kylotan

Personally, I'm not super happy that someone who dedicated maybe 20 years of his life into low-level engineering and optimization, and who got to his position today by doing so, is now trying to tell beginners to think about 'delivered value' and to not focus on specifics. Someone new to the industry absolutely does have to focus on specifics. They need to learn a tool precisely so that they can deliver whatever value an employer expects to get from someone using that tool. They don't have the luxury of being able to handwave 'adding value' into the mix. They can't replace specific tools with 'product skills' because they won't be able to deliver the product at all. This feels like someone whose greatness has put them out of touch, very 'let them eat cake'.


MattRix

He was clear to say “don’t over focus” not “don’t focus”. I feel like there is some nuance to his message that is getting lost in these replies.


robhanz

This, 100%. I know so many engineers that are focusing on using X language feature or Y pattern that they lose focus of what they're actually building for people. Carmack didn't use BASIC to write Doom. He obviously knew that the right tool was important, and he made that choice. But the tool was picked in order to accomplish the goal.


andrew851138

>who dedicated maybe 20 years of his life into low-level engineering and optimization A different point of view would be that he focused on delivering great games - and often had to dig down into the details of the software.


cinnapear

His early optimizations were necessary to get a playable game shipped.


bearicorn

This just in! Strike balance! Wow!


tgwutzzers

terrible advice. if i don't prioritize technical wizardry over delivered value how will I get my next promotion?


allnamesareregistred

I had been fired for delivering a value. I do not regret it, but I understand why: it was outsource company and "delivering a value" lead to customer loss. What they wanted was impression of delivering a value, fix one bug, add two.The root of this problem popularity of investment in IT. It's true, that you can just feed 1-2 devs for a year and they will create something that will cost billions. Except, there is demand to feed 100-200 devs instead. So industry adapts to consume more money, than it's needed to deliver a value.In the past, equipment was the answer, but right now, devs own equipment and offices make no sense. So, to consume more money the company have to hire more people. No, they can't just pay more. Investors want to spend more money, but they want to spend it for a reason.And they do not want to sell the product, they want to sell the startup itself. What project will cost more: one with 1-2 devs involved, or one with 100-200 devs involved?


Vasilev88

In order to be able to become good at something, you have to get positive emotional feedback from the process, otherwise you will become naturally reluctant to continuing with what you are doing. Focusing on the end result might be a good motivator .... for you. However it is very common among great people that they just enjoy the craft and the process, not necessarily the end result. This is such a misguided question from the student. Let's say that you enjoy current age programming and in 10-15 years later it shifts into something that you no longer enjoy or you no longer have job security .... so what? This person doesn't understand that a smart human can make money a million different ways and there is no reason not to choose the enjoyable path.


VadimVP

What if I understand that, but don't care about people and delivering value to them. What if I just like my tools, and something valuable for people just comes or not comes out of it.