6 ms·

Someone recently replied to me with comments by Dave Cutler, designer of the kernels for Windows NT/XP(...) and (Open)VMS: “I have a couple of sayings that are

by chasil 4y ago

Someone recently replied to me with comments by Dave Cutler, designer of the kernels for Windows NT/XP(...) and (Open)VMS: “I have a couple of sayings that are pertinent. The first is: ‘Successful people do what unsuccessful people won’t.’ The second is: ‘If you don’t put them [bugs] in, you don’t have to take them out.’ I am a person that wants to do the work. I don’t want to just think about it and let someone else do it. When presented with a programming problem, I formulate an appropriate solution and then proceed to write the code. While writing the code, I continually mentally execute the code in my head in an attempt to flush out any bugs. I am a great believer in incremental implementation, where a piece of the solution is done, verified to work properly, and then move on to the next piece. In my case, this leads to faster implementation with fewer bugs. Quality is my No. 1 constraint – always. I don’t want to produce any code that has bugs – none. “So my advice is be a thinker doer,” Cutler concluded. “Focus on the problem to solve and give it your undivided attention and effort. Produce high-quality work that is secure.” https://news.microsoft.com/features/the-engineers-engineer-computer-industry-luminaries-salute-dave-cutlers-five-decade-long-quest-for-quality/ https://news.microsoft.com/features/the-engineers-engineer-c... Unfortunately, I do not have this level of talent, but I do what I can.

patrck 4y ago
Though, if your bias is towards action, how do you avoid stepping on toes? These discussions seem like MBA brain-teasers, ie. there can't be any hard and fast rules, so each case needs to be individually worked out. There's probably a sub-reddit for this.
- kinos 4y ago
  Delegate the prioritization by using a template similar to this one. > "Hey, I noticed [this thing that I think might be a problem]. Would you like me to [do a specific action that would probably fix it] or move onto something else?"
- chasil 4y ago
  True to form, Cutler had a break with DEC, and they gave him a carte-blanche VAX "skunkworks" with Prism/Mica. DEC eventually shut this down, which prompted his departure for Microsoft. This is unfortunate for DEC, as they eventually poured the company into their Alpha RISC processor, which did not live as long as DEC hoped. Prism might have been a superior design. At this time, Microsoft was maintaining a UNIX kernel in their Xenix product, so they knew a good kernel engineer when they met one. Microsoft was the leading UNIX vendor in the early 80's. Cutler famously disparaged the UNIX kernel (his notable saying was "Get a byte, get a byte, get a byte byte byte" to the tune of the finale of Rossini's William Tell Overture). Microsoft dumped their Xenix onto SCO about this time. What is more interesting to me was Cutler's involvement with Azure. He must have had some sway over CBL-Mariner, Microsoft's RPM-based Linux distribution. Much of Cutler's earlier work is documented in the "Showstoppers" book: https://www.amazon.com/Show-Stopper-Breakneck-Generation-Microsoft/dp/0029356717 https://www.amazon.com/Show-Stopper-Breakneck-Generation-Mic... The book doesn't really delve into the Xenix decisions, if I remember correctly. Without Cutler, Microsoft would likely have ended up on a BSD kernel, as Apple did.
  - bluejekyll 4y ago
    Apple didn’t end up on a BSD kernel. They started on Mach (from NeXT) and then made it more performant with XNU by not being so pedantic about microkernels. BSD is just a supported kernel ABI. Edit: I just found these docs, so I suppose it’s a bit more complicated that I’m stating, I.e. there are portions of the FreeBSD kernel directly in macOS https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/BSD/BSD.html#//apple_ref/doc/uid/TP30000905-CH214-TPXREF103 https://developer.apple.com/library/archive/documentation/Da...
    - p_l 4y ago
      MacOS X essentially started by updating the NeXT core to latest OSFMK distribution, which was hybrid system (bsd server integrated into kernel space) powering the BSD alternative to SystemV - OSF/1 (most famous of them being DEC OSF/1 aka Digital Unix aka Compaq Tru64). They applied bits of FreeBSD to the bsd server code and over time improved its concurrency, but considerable portion of XNU is code that is called by bsd server but not part of bsd server (IOKit, among other things)
- chasil 4y ago
  I have another lost interview with Dave Cutler that Microsoft took down from their website about ten years ago. I can find and post it, if there is interest.
  - NegativeLatency 4y ago
    Interested!
    - chasil 4y ago
      I'll dig it up tomorrow.
      - wging 4y ago
        Any chance it also exists on web.archive.org?
      - indigodaddy 4y ago
        Following!
  - dewey 4y ago
    I just found one linked here: https://blog.codinghorror.com/showstopper/ https://blog.codinghorror.com/showstopper/ which points to "https://www.microsoft.com/windows2000/server/evaluation/news/fromms/kanoarchitect.asp&e=7620 https://www.microsoft.com/windows2000/server/evaluation/news...". Unfortunately I couldn't find a working copy in the Archive: https://web.archive.org/web/20041101000000*/https://www.microsoft.com/windows2000/server/evaluation/news/fromms/kanoarchitect.asp&e=7620 https://web.archive.org/web/20041101000000*/https://www.micr...
  - chasil 4y ago
    (1/3) I found this as an MHT file, edited as best I can. Maybe I should get this to archive.org? Date: Sat, 23 Oct 2004 09:40:05 -0700 From: Windows Contact Us <wincu@css.one.microsoft.com> We apologize for the delay in our response. I have attached "The Architects: First, Get the Spec Right" an interview with Cutler and Mark Lucovsky. Goldie, Microsoft.com Customer Support ___ The Architects: First, Get the Spec Right Once upon a time ... there was NT OS/2. Every month, Nadine Kano prowls the halls of Redmond to profile the real folks behind Windows 2000 development. This month: David Cutler and Mark Lucovsky, who helped guide the operating system from its infancy. "Well, we were just about to leave," David Cutler says from behind his desk. I'm five minutes late to my interview with Cutler and Mark Lucovsky, two of the original architects of the Microsoft Windows NT operating system. As I wilt into the carpet, I realize Lucovsky must have mentioned to his colleague how nervous I was about approaching them. After all, who the hell am I to be talking with these guys? They are developers' developers two of the visionaries behind the operating system that began as NT OS/2 and has evolved into Windows 2000. Cutler refuses virtually all interviews with the press, but he and Lucovsky are willing to talk to me, a program manager from down the hall. They probably find my nervousness amusing. Build it, ground up I was a college senior when Bill Gates personally recruited Cutler, Lucovsky, and others from Digital to begin the NT OS/2 project at Microsoft. Their quest was to build, from the ground up, an advanced PC operating system, something far beyond MS-DOS. NT signified "New Technology." One of my engineering classmates, David Treadwell, joined Microsoft to work on NT. I remember how excited he was to be a part of this obscure little development effort that none of us really understood. Remember that 1989 was before Windows 3.0. In 1989, Windows was still a nonentity.
- bfung 4y ago
  “Bias for action” is a nice catch phrase and not bad to get people out of paralysis. The other successful thing to add onto it, is to tell people what you’re going to do (ex, a high level 3 step plan, not more than 5), then do it. If there are objections, ask [what can be done] to mitigate the issue instead of arguing the points. Don’t “bias for action” and do something w/o setting expectations first.
  - malfist 4y ago
    I believe (and I could be entirely wrong here), "bias for action" comes from Amazon's leadership principles, it describes this trade off: >Bias for Action >Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking.
idontpost 4y ago
> Dave Cutler, designer of the kernels for Windows NT/XP(...) and (Open)VMS > I don’t want to produce any code that has bugs – none Really though? I'm not sure I buy a word of that.
- p_l 4y ago
  A lot of NT hardening happening over last ~20 years was effectively enabling access controls that were set too lax previously or even disabled, all due to performance issues (GDI being moved in-kernel, with all the security issues, was also due to performance problems of NT3.x) The NT kernel is quite nice and solid, the problem is that not everything built on it followed all of the design rules.
- chasil 4y ago
  He did the very best that could be expected in the early '90s. It was exemplary coding, and very little of its fundamentals have changed. I have some assertion on this from an interview in the late aughts - most of the problems were in layers above the kernel. That being said, even VMS is not without flaws (we still run it for our manufacturing floor): https://www.theregister.com/2018/02/06/openvms_vulnerability/ https://www.theregister.com/2018/02/06/openvms_vulnerability... Nobody's perfect.
  - Veserv 4y ago
    No, the best that could be expected in the early 90’s is formal proofs of security enforcing multiple independent levels of security (MILS) allowing the execution of arbitrary, malicious programs on the same systems handling TOP SECRET data in complete safety as achieved by TCSEC Class A1 certified systems contemporaneously. In contrast, OpenVMS only ever achieved C2, security enhanced VMS B1 [1], and the NT kernel C2 [2]. NT kernel based systems subsequently maximally achieved EAL4+ indicating independent verification that it is adequate to protect against “casual, and inadvertent attacks”, but failed to demonstrate resistance against attackers with a “moderate” attack potential. So, no, it is not the very best that could be expected in the early 90’s. [1] https://web.archive.org/web/20151119105617/http://h71000.www7.hp.com/openvms/products/sevms/ https://web.archive.org/web/20151119105617/http://h71000.www... [2] https://www.microsoftpressstore.com/articles/article.aspx?p=2228450 https://www.microsoftpressstore.com/articles/article.aspx?p=...
Simon_O_Rourke 4y ago
Yes but quality, naturally enough, takes more time. And while this might be great for organizations with plenty of buffer, for any start-up it has to be that "good today beats perfect tomorrow".
- dagss 4y ago
  Buggy code can be a real timesink for startups...the failures often cannot be ignored too long, they just sit and mature and compound some interest before they have to be fixed anyway. And writing bug free/low bug code is about experience level and how your development methodology is -- not about spending more wall clock time. (I.e. for the quality you may spend more on salaries per hour, but not more hours -- probably a very good idea for a startup IMO) I believe that in many situations high quality code is a LOWER net investment than low quality code.
  - leetrout 4y ago
    I think this captures my experiences perfectly. Building something the right way usually means it runs better with much lower maintenance overhead and is easier to extend or replace later.
  - dhzhzjsbevs 4y ago
    > I believe that in many situations high quality code is a LOWER net investment than low quality code. This statement requires one caveat: your codebase sunset date. Without it you can justify basically anything on the quality slider.
    - dagss 4y ago
      I meant in the context of 2-3 years before a rewrite I guess. Code with bugs can just sink your team in the first months after hitting production..
- dhzhzjsbevs 4y ago
  There is a difference between quality and overengineered features nobody asked for. Nobody is suggesting we "do everything in the ideal way". We're suggesting taking 5 minutes to think about the thing you're writing in the next 30. It produces less buggy code, and likely, be able to complete the task with less iteration because you made the mistakes in your head and changed plans before you wrote them out. I close out 30 tickets a week, other teams at our company are lucky if they close out that many as a team. I'm not trading quantity for quality at all, I'm simply choosing to do the things that matter and I ignore everything else.
davedx 4y ago
Hmm. There's definitely things to be learned picking up things that other people won't touch, but I would also qualify it more: "Successful people choose their battles" You can spend your entire career fixing other peoples' crappy bugs because nobody else can be bothered. That's not really going to make you successful, it's just going to make you a good bug fixer. Choose problems that other people don't want to touch because they're hard or challenging, or because they're a core, valuable part of something. That's what's brought me succeess ;) (and headaches)
- ankitpati 4y ago
  Core, not chore. Most pertinent advice I’ve seen in a while.
  - copperx 4y ago
    Can you explain a bit?
- cafard 4y ago
  Yossi Kreinen (the C++ Frequently Questioned Answers guy) has a good post or two about choosing battles or projects.
  - malfist 4y ago
    Do you mind to share it?
  - monkeyshelli 4y ago
    Would you please mind sharing the links? My past experience of picking up projects hasn't been stellar so wouldn't mind to learn new viewpoints.
  - cafard 4y ago
    http://yosefk.com/blog/10x-more-selective.html http://yosefk.com/blog/10x-more-selective.html
- deleted 4y ago
formerkrogemp 4y ago
We can't and shouldn't all aim to produce the Mona Lisa or Starry Night. Such expectations and perfectionism are unhealthy and often counterproductive. Sometimes you just need to showcase the product and fix the issues in beta. Going slow with low bug counts is nice sometimes and in theory, but certainly not every exception or edge case will be forseeable or preventable even with an incremental approach.
DeathArrow 4y ago
>I don’t want to produce any code that has bugs – none. And there's the reverse thinking: let me intentionally introduce some bugs, so when I will be tasked with solving them I can fix them in 5 minutes and take a good sleep for the rest of the sprint.
bitL 4y ago
The problem of advice like these is that the "modern" Scrum Master would demolish this approach in favor of a predictable pace with shallow depth. DC could only become successful in environments without any Agile/PMP certified PM.
- Aeolun 4y ago
  I find that at Staff+ level you do get the ability to do these things again. Generally you are not beholden to the PM’s and sprints any more. Most of the work you do cannot be categorized as feature factory stuff.
koonsolo 4y ago
Let me give some senior developer feedback on these statements. Developing kernels is a highly technical job. I can imagine that you have to think hard before writing any code. Once you figure out a proper solution, you can invest some time into writing high-quality code. But remark that no code is written bug-free the first time! Now contrast this with a consumer facing application. The biggest challenge there is not stability or technical structure. The biggest challenge is to provide a useful, user friendly application. You cannot just think this up in your head and hope all is fine. The "no plan survives contact with the enemy" very much applies here. There is no point in investing into code stability when that code has a high chance of getting thrown away. Get the "useful and user friendly" figured out very fast, using an iterative approach. And only then start focussing on stability and all the rest. Plus, sometimes it makes more sense business wise to shift focus more towards features instead of stability. Anyway, each project is different. So when you see advice, make sure you first check if it applies in your case or not.
- User23 4y ago
  Correctness and pleasantness are entirely distinct. In most cases incorrectness has little or no effect on commercial success whereas unpleasantness will sink a product instantly. There are some areas where incorrectness is also highly unpleasant, kernels and compilers being two examples.
- mooreds 4y ago
  > ... when you see advice, make sure you first check if it applies in your case or not. I wish everyone understood this. There are four things you need to do to successfully apply advice: 1. Discover it (lots of ways to do this, even more now in the age of the internet). 2. Determine if it is good or not (you can rely on the wisdom of the crowds, other people's judgement based on qualifications, books, references, etc). 3. Determine if it applies to you (you have to make this call, requires thinking about the context of the advice giver and your situation). 4. Actually apply the advice. This requires making the changes suggested and is intrinsically individual. Step 1 happens pretty naturally, and we're well set up for step 2 (though of course people get fleeced by snake oil salesmen all the time). Step 4 is intuitive. But, don't forget step 3!
- 4y ago
nimbius 4y ago
So, coming from a mechanic/blue-collar perspective the idea that everything has to be your job is an insanely dangerous practice. We absolutely have a "not my job" mentality because there are countless instances where poorly trained/inexperienced diagnostic technicians and day laborers have caused catastrophic loss of life and property damage. Is there no room in coding for inexperience? what is the price of a job half done poorly? "Successful people do what unsuccessful people won’t." is, in my industry, a neat way to start the story of how you lost your hand.
- dzolvd 4y ago
  in software, this is where "catastrophic" data leaks and security vulnerabilities come from, an engineer or team deciding to roll their own version of a security or cryptography library without having the proper experience to even know what they don't know.
- rawgabbit 4y ago
  In tech, the consulting industry is full of "job half done poorly". Consultants overpromise and underdeliver. They take the money and run. Yes, it somewhat works. If you have a bug, no one can help you because their code is a giant ball of spaghetti that requires a Rosetta Stone to decipher. Which they will not give you without you paying more money. Within five years, you are likely to ditch that train wreck and hire a bunch of new consultants to rewrite what will probably be another slow burning dumpster fire.
- quartesixte 4y ago
  Unfortunately, in many places, “that’s not my job” has been weaponized by people to avoid pulling their weight or to fill in a critical gap. Often in very low-stakes situations. “That’s not my job” for industrial/manufacturing is absolutely critical and should not be downplayed. But refusing to teach the newbie next to you how to use the Jira ticket system because it’s “not your job” is counterproductive.

by chasil 4y ago

patrck 4y ago

Though, if your bias is towards action, how do you avoid stepping on toes? These discussions seem like MBA brain-teasers, ie. there can't be any hard and fast rules, so each case needs to be individually worked out. There's probably a sub-reddit for this.

kinos 4y ago
Delegate the prioritization by using a template similar to this one. > "Hey, I noticed [this thing that I think might be a problem]. Would you like me to [do a specific action that would probably fix it] or move onto something else?"
chasil 4y ago
True to form, Cutler had a break with DEC, and they gave him a carte-blanche VAX "skunkworks" with Prism/Mica. DEC eventually shut this down, which prompted his departure for Microsoft. This is unfortunate for DEC, as they eventually poured the company into their Alpha RISC processor, which did not live as long as DEC hoped. Prism might have been a superior design. At this time, Microsoft was maintaining a UNIX kernel in their Xenix product, so they knew a good kernel engineer when they met one. Microsoft was the leading UNIX vendor in the early 80's. Cutler famously disparaged the UNIX kernel (his notable saying was "Get a byte, get a byte, get a byte byte byte" to the tune of the finale of Rossini's William Tell Overture). Microsoft dumped their Xenix onto SCO about this time. What is more interesting to me was Cutler's involvement with Azure. He must have had some sway over CBL-Mariner, Microsoft's RPM-based Linux distribution. Much of Cutler's earlier work is documented in the "Showstoppers" book: https://www.amazon.com/Show-Stopper-Breakneck-Generation-Microsoft/dp/0029356717 https://www.amazon.com/Show-Stopper-Breakneck-Generation-Mic... The book doesn't really delve into the Xenix decisions, if I remember correctly. Without Cutler, Microsoft would likely have ended up on a BSD kernel, as Apple did.
- bluejekyll 4y ago
  Apple didn’t end up on a BSD kernel. They started on Mach (from NeXT) and then made it more performant with XNU by not being so pedantic about microkernels. BSD is just a supported kernel ABI. Edit: I just found these docs, so I suppose it’s a bit more complicated that I’m stating, I.e. there are portions of the FreeBSD kernel directly in macOS https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/BSD/BSD.html#//apple_ref/doc/uid/TP30000905-CH214-TPXREF103 https://developer.apple.com/library/archive/documentation/Da...
  - p_l 4y ago
    MacOS X essentially started by updating the NeXT core to latest OSFMK distribution, which was hybrid system (bsd server integrated into kernel space) powering the BSD alternative to SystemV - OSF/1 (most famous of them being DEC OSF/1 aka Digital Unix aka Compaq Tru64). They applied bits of FreeBSD to the bsd server code and over time improved its concurrency, but considerable portion of XNU is code that is called by bsd server but not part of bsd server (IOKit, among other things)
chasil 4y ago
I have another lost interview with Dave Cutler that Microsoft took down from their website about ten years ago. I can find and post it, if there is interest.
- NegativeLatency 4y ago
  Interested!
  - chasil 4y ago
    I'll dig it up tomorrow.
    - wging 4y ago
      Any chance it also exists on web.archive.org?
    - indigodaddy 4y ago
      Following!
- dewey 4y ago
  I just found one linked here: https://blog.codinghorror.com/showstopper/ https://blog.codinghorror.com/showstopper/ which points to "https://www.microsoft.com/windows2000/server/evaluation/news/fromms/kanoarchitect.asp&e=7620 https://www.microsoft.com/windows2000/server/evaluation/news...". Unfortunately I couldn't find a working copy in the Archive: https://web.archive.org/web/20041101000000*/https://www.microsoft.com/windows2000/server/evaluation/news/fromms/kanoarchitect.asp&e=7620 https://web.archive.org/web/20041101000000*/https://www.micr...
- chasil 4y ago
  (1/3) I found this as an MHT file, edited as best I can. Maybe I should get this to archive.org? Date: Sat, 23 Oct 2004 09:40:05 -0700 From: Windows Contact Us <wincu@css.one.microsoft.com> We apologize for the delay in our response. I have attached "The Architects: First, Get the Spec Right" an interview with Cutler and Mark Lucovsky. Goldie, Microsoft.com Customer Support ___ The Architects: First, Get the Spec Right Once upon a time ... there was NT OS/2. Every month, Nadine Kano prowls the halls of Redmond to profile the real folks behind Windows 2000 development. This month: David Cutler and Mark Lucovsky, who helped guide the operating system from its infancy. "Well, we were just about to leave," David Cutler says from behind his desk. I'm five minutes late to my interview with Cutler and Mark Lucovsky, two of the original architects of the Microsoft Windows NT operating system. As I wilt into the carpet, I realize Lucovsky must have mentioned to his colleague how nervous I was about approaching them. After all, who the hell am I to be talking with these guys? They are developers' developers two of the visionaries behind the operating system that began as NT OS/2 and has evolved into Windows 2000. Cutler refuses virtually all interviews with the press, but he and Lucovsky are willing to talk to me, a program manager from down the hall. They probably find my nervousness amusing. Build it, ground up I was a college senior when Bill Gates personally recruited Cutler, Lucovsky, and others from Digital to begin the NT OS/2 project at Microsoft. Their quest was to build, from the ground up, an advanced PC operating system, something far beyond MS-DOS. NT signified "New Technology." One of my engineering classmates, David Treadwell, joined Microsoft to work on NT. I remember how excited he was to be a part of this obscure little development effort that none of us really understood. Remember that 1989 was before Windows 3.0. In 1989, Windows was still a nonentity.
bfung 4y ago
“Bias for action” is a nice catch phrase and not bad to get people out of paralysis. The other successful thing to add onto it, is to tell people what you’re going to do (ex, a high level 3 step plan, not more than 5), then do it. If there are objections, ask [what can be done] to mitigate the issue instead of arguing the points. Don’t “bias for action” and do something w/o setting expectations first.
- malfist 4y ago
  I believe (and I could be entirely wrong here), "bias for action" comes from Amazon's leadership principles, it describes this trade off: >Bias for Action >Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking.

idontpost 4y ago

> Dave Cutler, designer of the kernels for Windows NT/XP(...) and (Open)VMS > I don’t want to produce any code that has bugs – none Really though? I'm not sure I buy a word of that.

p_l 4y ago
A lot of NT hardening happening over last ~20 years was effectively enabling access controls that were set too lax previously or even disabled, all due to performance issues (GDI being moved in-kernel, with all the security issues, was also due to performance problems of NT3.x) The NT kernel is quite nice and solid, the problem is that not everything built on it followed all of the design rules.
chasil 4y ago
He did the very best that could be expected in the early '90s. It was exemplary coding, and very little of its fundamentals have changed. I have some assertion on this from an interview in the late aughts - most of the problems were in layers above the kernel. That being said, even VMS is not without flaws (we still run it for our manufacturing floor): https://www.theregister.com/2018/02/06/openvms_vulnerability/ https://www.theregister.com/2018/02/06/openvms_vulnerability... Nobody's perfect.
- Veserv 4y ago
  No, the best that could be expected in the early 90’s is formal proofs of security enforcing multiple independent levels of security (MILS) allowing the execution of arbitrary, malicious programs on the same systems handling TOP SECRET data in complete safety as achieved by TCSEC Class A1 certified systems contemporaneously. In contrast, OpenVMS only ever achieved C2, security enhanced VMS B1 [1], and the NT kernel C2 [2]. NT kernel based systems subsequently maximally achieved EAL4+ indicating independent verification that it is adequate to protect against “casual, and inadvertent attacks”, but failed to demonstrate resistance against attackers with a “moderate” attack potential. So, no, it is not the very best that could be expected in the early 90’s. [1] https://web.archive.org/web/20151119105617/http://h71000.www7.hp.com/openvms/products/sevms/ https://web.archive.org/web/20151119105617/http://h71000.www... [2] https://www.microsoftpressstore.com/articles/article.aspx?p=2228450 https://www.microsoftpressstore.com/articles/article.aspx?p=...

Simon_O_Rourke 4y ago

Yes but quality, naturally enough, takes more time. And while this might be great for organizations with plenty of buffer, for any start-up it has to be that "good today beats perfect tomorrow".

dagss 4y ago
Buggy code can be a real timesink for startups...the failures often cannot be ignored too long, they just sit and mature and compound some interest before they have to be fixed anyway. And writing bug free/low bug code is about experience level and how your development methodology is -- not about spending more wall clock time. (I.e. for the quality you may spend more on salaries per hour, but not more hours -- probably a very good idea for a startup IMO) I believe that in many situations high quality code is a LOWER net investment than low quality code.
- leetrout 4y ago
  I think this captures my experiences perfectly. Building something the right way usually means it runs better with much lower maintenance overhead and is easier to extend or replace later.
- dhzhzjsbevs 4y ago
  > I believe that in many situations high quality code is a LOWER net investment than low quality code. This statement requires one caveat: your codebase sunset date. Without it you can justify basically anything on the quality slider.
  - dagss 4y ago
    I meant in the context of 2-3 years before a rewrite I guess. Code with bugs can just sink your team in the first months after hitting production..
dhzhzjsbevs 4y ago
There is a difference between quality and overengineered features nobody asked for. Nobody is suggesting we "do everything in the ideal way". We're suggesting taking 5 minutes to think about the thing you're writing in the next 30. It produces less buggy code, and likely, be able to complete the task with less iteration because you made the mistakes in your head and changed plans before you wrote them out. I close out 30 tickets a week, other teams at our company are lucky if they close out that many as a team. I'm not trading quantity for quality at all, I'm simply choosing to do the things that matter and I ignore everything else.

davedx 4y ago

Hmm. There's definitely things to be learned picking up things that other people won't touch, but I would also qualify it more: "Successful people choose their battles" You can spend your entire career fixing other peoples' crappy bugs because nobody else can be bothered. That's not really going to make you successful, it's just going to make you a good bug fixer. Choose problems that other people don't want to touch because they're hard or challenging, or because they're a core, valuable part of something. That's what's brought me succeess ;) (and headaches)

ankitpati 4y ago
Core, not chore. Most pertinent advice I’ve seen in a while.
- copperx 4y ago
  Can you explain a bit?
cafard 4y ago
Yossi Kreinen (the C++ Frequently Questioned Answers guy) has a good post or two about choosing battles or projects.
- malfist 4y ago
  Do you mind to share it?
- monkeyshelli 4y ago
  Would you please mind sharing the links? My past experience of picking up projects hasn't been stellar so wouldn't mind to learn new viewpoints.
- cafard 4y ago
  http://yosefk.com/blog/10x-more-selective.html http://yosefk.com/blog/10x-more-selective.html
deleted 4y ago

formerkrogemp 4y ago

We can't and shouldn't all aim to produce the Mona Lisa or Starry Night. Such expectations and perfectionism are unhealthy and often counterproductive. Sometimes you just need to showcase the product and fix the issues in beta. Going slow with low bug counts is nice sometimes and in theory, but certainly not every exception or edge case will be forseeable or preventable even with an incremental approach.

DeathArrow 4y ago

>I don’t want to produce any code that has bugs – none. And there's the reverse thinking: let me intentionally introduce some bugs, so when I will be tasked with solving them I can fix them in 5 minutes and take a good sleep for the rest of the sprint.

bitL 4y ago

The problem of advice like these is that the "modern" Scrum Master would demolish this approach in favor of a predictable pace with shallow depth. DC could only become successful in environments without any Agile/PMP certified PM.

Aeolun 4y ago
I find that at Staff+ level you do get the ability to do these things again. Generally you are not beholden to the PM’s and sprints any more. Most of the work you do cannot be categorized as feature factory stuff.

koonsolo 4y ago

Let me give some senior developer feedback on these statements. Developing kernels is a highly technical job. I can imagine that you have to think hard before writing any code. Once you figure out a proper solution, you can invest some time into writing high-quality code. But remark that no code is written bug-free the first time! Now contrast this with a consumer facing application. The biggest challenge there is not stability or technical structure. The biggest challenge is to provide a useful, user friendly application. You cannot just think this up in your head and hope all is fine. The "no plan survives contact with the enemy" very much applies here. There is no point in investing into code stability when that code has a high chance of getting thrown away. Get the "useful and user friendly" figured out very fast, using an iterative approach. And only then start focussing on stability and all the rest. Plus, sometimes it makes more sense business wise to shift focus more towards features instead of stability. Anyway, each project is different. So when you see advice, make sure you first check if it applies in your case or not.

User23 4y ago
Correctness and pleasantness are entirely distinct. In most cases incorrectness has little or no effect on commercial success whereas unpleasantness will sink a product instantly. There are some areas where incorrectness is also highly unpleasant, kernels and compilers being two examples.
mooreds 4y ago
> ... when you see advice, make sure you first check if it applies in your case or not. I wish everyone understood this. There are four things you need to do to successfully apply advice: 1. Discover it (lots of ways to do this, even more now in the age of the internet). 2. Determine if it is good or not (you can rely on the wisdom of the crowds, other people's judgement based on qualifications, books, references, etc). 3. Determine if it applies to you (you have to make this call, requires thinking about the context of the advice giver and your situation). 4. Actually apply the advice. This requires making the changes suggested and is intrinsically individual. Step 1 happens pretty naturally, and we're well set up for step 2 (though of course people get fleeced by snake oil salesmen all the time). Step 4 is intuitive. But, don't forget step 3!
4y ago

nimbius 4y ago

So, coming from a mechanic/blue-collar perspective the idea that everything has to be your job is an insanely dangerous practice. We absolutely have a "not my job" mentality because there are countless instances where poorly trained/inexperienced diagnostic technicians and day laborers have caused catastrophic loss of life and property damage. Is there no room in coding for inexperience? what is the price of a job half done poorly? "Successful people do what unsuccessful people won’t." is, in my industry, a neat way to start the story of how you lost your hand.

dzolvd 4y ago
in software, this is where "catastrophic" data leaks and security vulnerabilities come from, an engineer or team deciding to roll their own version of a security or cryptography library without having the proper experience to even know what they don't know.
rawgabbit 4y ago
In tech, the consulting industry is full of "job half done poorly". Consultants overpromise and underdeliver. They take the money and run. Yes, it somewhat works. If you have a bug, no one can help you because their code is a giant ball of spaghetti that requires a Rosetta Stone to decipher. Which they will not give you without you paying more money. Within five years, you are likely to ditch that train wreck and hire a bunch of new consultants to rewrite what will probably be another slow burning dumpster fire.
quartesixte 4y ago
Unfortunately, in many places, “that’s not my job” has been weaponized by people to avoid pulling their weight or to fill in a critical gap. Often in very low-stakes situations. “That’s not my job” for industrial/manufacturing is absolutely critical and should not be downplayed. But refusing to teach the newbie next to you how to use the Jira ticket system because it’s “not your job” is counterproductive.