7 ms·

The Code You Don't Write

134 points by menacingly 13y ago

gngeal 13y ago
"The cheapest, fastest and most reliable components are those that aren’t there." -- Gordon Bell
- pjmorris 13y ago
  I first read this in the 'Bumper-Sticker Computer Science' column/chapter of More Programming Pearls, Jon Bentley. Great aphorism, great book.
wonnage 13y ago
It's amusing how quickly programmers-turned-managers forget their roots. Look here: I used to get a huge feeling of satisfaction from a weekend spent working on a clever hack. I would spend serious effort making something run twice as quickly, even when there wasn't a problem with how quickly it was running in the first place. Meeting those types of challenges was my primary motivator. This is how you were motivated before they gave you a manager hat. This is how the people you manage think. And I wager that this mindset isn't wrong by any stretch of the imagination - as a programmer, I love working around people who program for the sake of programming, who find fun and satisfaction in writing code. I don't mean to suggest the perception of code as just one of many means to an end is wrong either; it actually makes perfect business sense. It's something managers need to understand. But in your "enlightenment" you've forgotten what made you tick in the first place - how do you translate your new business-value-driven mindset to something the people under you (who don't have that mindset) can appreciate? Hint: it's not by telling them their cool hacks are useless. And we wonder why programmers distrust management.
- beat 13y ago
  Avoiding writing code is quite often a "cool hack".
- beat 13y ago
  Actually, let me put this another way... back in the original dotcom era, I worked at a startup that decided to write a BIOS. With the amount of hardware we'd be selling, it'd save a million dollars! Well worth six man-months or so of work, right? WRONG. That was six man-months of critical programmer time when the time and money was running out, and all we learned was that we couldn't do it in a 512k PROM (not with our design anyway), and upgrading to a 1mb PROM would have cost more than a license from Phoenix for their BIOS. That's what happens when you let the inmates run the asylum. Programmers are fools, for the most part. They don't understand what problem they're really trying to solve. We thought we were solving a cost-of-production problem for a fully scaled business. That wasn't the problem. The PROBLEM was NOT DYING. And that meant getting a working product out the door as quickly as possible, even if it cost more.
  - lemming 13y ago
    Programmers are fools, for the most part. They don't understand what problem they're really trying to solve. That's a little harsh. I think it's fairer to say that they often don't have insight into the wider strategic objectives of the company, and that's as much a company failing as anything. I'm now a firm believer in sharing e.g. revenue numbers with everyone in the company and explaining why they're important - people are much more willing to accept things when they understand the wider picture.
- deleted 13y ago
  [deleted]
- mturmon 13y ago
  It's not just managers vs. coders. It's also experienced coders vs. novices. You get tired of writing a pile of code that solves the problem the wrong way, so after 10 or so iterations of un-appreciated or un-used code, you learn to try to look at the big picture instead of always trying to isolate the problem into a fun programming exercise. There is a management lesson here in being sure the right people are working on the right stuff. If you may need process improvement to generate the nightly reports by the next morning, don't send someone who loves to re-implement scripts in C. Or, if you're the person who loves to re-implement scripts in C, realize that your prospects may be limited.
- chaz 13y ago
  > Hint: it's not by telling them their cool hacks are useless. No, of course not. It's by showing/encouraging more ways to hack a solution. Writing code is one of many tools that can be used, and as the adage goes: "if the only tool you have is a hammer, everything looks like a nail." You can't pick the best tool for the job if you only want to use one tool.
0xdeadbeefbabe 13y ago
After fiddling with gnunet for too long I'm wondering if the code you don't write will or will not solve the NSA spying problem. I'm in the will not camp so far because gnunet isn't working, and even if it connected to some peers I wouldn't know how to verify my anonimity. They also say something like you might be protected from the law if you click Y here. But I don't want a not guilty verdict, I don't even want to go to trial.
mgerals 13y ago
Strictly relying on 3rd-party code without understanding the algorithms and complexities can lead to just as many problems. In my opinion you still better be a very good coder when relying on libraries, just plug and play will fail you sooner than later. I have seen my fair share of this. When requirements slightly change and you have to adapt a library, suddenly you have to deal with 20k (or more) lines of code and have no idea where to even start. You may just need to use a tiny part of that library but the code is so tightly bundled and abstracted (for good reason) that you have to dig through layers and layers just to make a simple change. You should at least understand the complexities when relying on 3rd-party code, the Go dependency hell of the game "Haunts" comes to mind (but I don't remember the details, so probably not the best example). A few additional thoughts: 1. I said "plug and play will fail you sooner than later" -- for most startups that "later" never happens or is not of concern. How often has a startup's code-base made into an acquiring company's production systems without a complete rewrite? 2. Also, when reading some of these posts, I tend to look at the author's motivation/background. This is a somewhat controversial claim (on HN) -- so it is bound to stir up some interest/pubilicty. And also, this is probably not the worst way to court some new clients ("hey, we write less code and waste less of your money"). But I do believe that the re-use approach would be well-suited for short-lived marketing campaigns, as opposed to some other software -- think limited scope and fixed requirements. I'd do the same if I had to work on several campaigns that are probably all similar to a degree.
- chn 13y ago
  I think there can be good reasons to choose mature library that solves complex problem (even if you don't understand the code) instead of writing your own code. I find writing a simple wrapper around big libraries a good practice, it should limit the external library features to what you really need, give you more control on how it's used and allow to switch to other library or even write your own code with much less effort.
tsm 13y ago
Working as one of two programmers at a startup has really reinforced this for me. As a student and even when I worked at BigCo, I loved taking the time to do things myself, do things Right (with the capital R), and so forth. Now, since I'm surrounded by business people, I'm thinking more in terms of value-provided, not cool-hacks-provided. It's made me ship better things a lot faster and make more people happy. And, really, that's the end goal.
danso 13y ago
I think this is more about "feature creep" than specifically about code, though the OP's point is well taken. But the distinction matters: the dilemma I find myself facing is: do I write that extra library or test to make sure things work? Do I take the time to refactor? Is it worth the time? In those situations, it isn't at all an easy question, unless you know the problem you face requires a one-off software solution with little liability for maintenance.
- cdmo 13y ago
  Yes, I think the point of the story was about being business minded rather than indulging your own programming interests and prowess. Or in other words, the feature creep that you add yourself. This is advice is well timed for me ;)
captn3m0 13y ago
This is my constant advice to my startup-hungry-friends. I constantly tell them: "Coding it should be the last item on your list."
rmcastil 13y ago
I've come to a similar conclusion but I tend to think of it as solving little problems with the simplest solution possible. Don't pre optimize and don't pre abstract. This is a thought process I think you arrive at when you're running your own business or in some sort of managerial role. You start realizing the constraints (time, budget, resources, etc) involved in building software. When we first come into the world of software we just want to write awesome code. But to truly evolve as a developer you need to start asking real questions regarding what you are building. Are we making the budget bleed by spending 3 weeks on making the most beautiful piece of code possible for a feature when it was originally estimated to take two days? Can an open source library be used instead of us trying to build something from the ground up? How does this feature add real value to the users of this product?
themckman 13y ago
It gets me closer to adding value directly, instead of shoehorning my preferred solution onto a problem. But shoehorning my elaborate solution onto the problem is the funnest part. Providing value is easy and boring...
btilly 13y ago
Let me turn this around. Most feature requests arrive from a user telling you how they think you should solve some other problem. If you can figure out the real problem and solve it better, that will be an improvement over delivering the exact request as given. (If you can't solve the real problem, though, or you misunderstand it, that's worse.) For example at one company I was asked to speed up a report. The problem was that it was running too slowly and was timing out in the browser. Instead of tackling that fun optimization challenge, I built a feature that would cause any report that took more than a minute to run to be emailed to the current user. My manager said that he received more thank yous for that feature than for everything else the team had done in the previous 6 months. At another company I received a request to add a feature that would prioritize pushing specific pieces of data to the website. (We'd had some stability problems, and they had no visibility into what was happening.) I knew that adding this prioritization feature would further destabilize the data transfer logic that I was trying to make more robust, talked to my manager, and refused the request. The senior executive requesting the feature tried to get another co-worker to do it instead, that one asked me innocently how to go about it, I got him to push back. Several months later I got enough of a break from other projects to consider the prioritization feature and asked the executive whether he still needed it. His response? "It has been months since data took more than 5 minutes to get to the website, I'm fine." Also it can help to generalize your solution. At a third company I built a reporting system where instead of just plugging inputs, every form field could template the SQL that was being used. So a report could also generate drilldowns of itself, and you could combine these in a very flexible way. After a while over 2/3 of the special report requests that I got could be immediately resolved by showing that it was available if you combined two features that had been added for other users doing something else. (My turnaround time for other requests tended to be under 2 hours - and the features, documented, were available for anyone who needed them.) Programmers do not provide value by writing code. We provide value by solving problems more quickly and cheaply than the alternative. The better you solve problems, the more value you provide.
- drhayes9 13y ago
  That’s why it was left to wizards, who knew how to handle it safely. Not doing any magic at all was the chief task of wizards—not “not doing magic” because they couldn’t do magic, but not doing magic when they could do and didn’t. Any ignorant fool can fail to turn someone else into a frog. You have to be clever to refrain from doing it when you knew how easy it was. There were places in the world commemorating those times when wizards hadn’t been quite as clever as that, and on many of them the grass would never grow again. - Terry Pratchett
beat 13y ago
Code is not an end in itself, only a means to an end.
losethos 13y ago
I wrote all 130,000 lines myself. I hired an artist for $3000 for some work. You would be advised not to fuck with me -- God is right here and will send you to hell. God says... Foundation floating parched Ask thats_just_wrong comely guidest employ formlessness sigh -not definite so_let_it_be_done distances paper God_smack recite
salmonellaeater 13y ago
This is spot on. Every time you solve a problem without writing code, you avoid possible bugs, future maintenance, and legal issues, and you don't spend time. The second-best code, after code you avoided writing, is code you can delete and as a side effect solve a problem. The less code, the better.
- j-kidd 13y ago
  Those are certainly valid points, but I can't help but feel like the OP is going down a slippery slope, and will soon start contracting out coding work to 3rd party, which would then comes back full of bugs and doesn't mesh nicely with existing architecture, thus requiring full-time maintenance from internal staffs anyway.
  - menacingly 13y ago
    I can see how you would have come away with that impression. We produce a lot of code, so much in fact that it didn't even occur to me to state the value in doing so. We definitely do and will continue to keep a talented team busy.
richkuo 13y ago
Every non-technical entrepreneur or co-founder needs to read this. Twice. You would not believe how many non-technical people think that programming is a critical component to the problems they are trying to solve.
QEDturtles 13y ago
This is a really cool article in that it shows the transition of one developer into an architect. I think the grief the author is taking in some of the comments has more to do with presentation than content. The weekends of clever hacks that he mentioned were essential to his development as they are for all of us. The weekend is a good time for clever hacks. If they have useful business implications all the better. Exciting, innovated packages often sprout from a developer's desire for a more elegant, stable, focused, or powerful solution for a problem or a problemset. These innovations should be abstracted into reusable packages and reused. However, in a business environment, developers need to be focused on solving problems for users. They need to do so in the most stable and sane possible manner. That means that code should be a last resort when a solution has not already been written. If you miss your weekend hackathon, contribute back to the packages that you found helpful. This way, you can get your kicks from clever new hacks and improve several of your existing projects in one fell swoop! Writing code (and lots of it) is essential to growing as a developer. Unfortunately, it's often a detriment to software projects.
Mithaldu 13y ago
It took him becoming a manager to figure out what the Programmer's Virtues* are about? * http://threevirtues.com/ http://threevirtues.com/
JDGM 13y ago
I enjoyed this but on the surface reading didn't like his "it makes me think an octave higher" line, and on reading the context from Sivers (an excellent article that, btw) I even more didn't like it. The analogy just didn't seem appropriate. However, after some thought I felt the paragraph after with the bulletpoints does actually line up quite nicely (albeit rather obliquely) with what Sivers was talking about and I think I get it now, the finer points just weren't immediately obvious. This a minor niggle but I think that he could have explained that part better, and without requiring a whole other article for context (no matter how good that article is!).
- menacingly 13y ago
  OP here. That's really valid feedback and I'll keep it in mind in the future.
jacob019 13y ago
This really resonates with me. I'm having a terrible time getting high quality code from my team. Software is expensive to develop, and as a tech company we always try to solve every problem with code first. I'm going to make more of an effort to think about our problems beyond the lens of code, thanks!
6d0debc071 13y ago
I don't think that too many people like the feeling that their work is going to be useless. On the other hand, if you don't have a larger overview of a problem domain it can be difficult to feel that you're making progress doing anything other than optimising and abstracting. On the other hand there are reasons why the Linux kernel runs dramatically better designed than Windows.
- ams6110 13y ago
  The NT kernel is well designed. Windows is full of a lot of other cruft though, a lot of which isn't.
prayag 13y ago
Sometimes you have to write software to make all the other option much more efficient. Let give an example, we at MobileWorks (https://premier.mobileworks.com https://premier.mobileworks.com) are in business of providing virtual temps to businesses. Since we are built to scale, the entire team has virtually unlimited supply of temporary labor and we use it A LOT. However, in a lot of cases a little bit of code actually makes the temps much more efficient. That's the real value of code. Making the mundane much more efficient.

134 points by menacingly 13y ago

gngeal 13y ago

"The cheapest, fastest and most reliable components are those that aren’t there." -- Gordon Bell

pjmorris 13y ago
I first read this in the 'Bumper-Sticker Computer Science' column/chapter of More Programming Pearls, Jon Bentley. Great aphorism, great book.

wonnage 13y ago

It's amusing how quickly programmers-turned-managers forget their roots. Look here: I used to get a huge feeling of satisfaction from a weekend spent working on a clever hack. I would spend serious effort making something run twice as quickly, even when there wasn't a problem with how quickly it was running in the first place. Meeting those types of challenges was my primary motivator. This is how you were motivated before they gave you a manager hat. This is how the people you manage think. And I wager that this mindset isn't wrong by any stretch of the imagination - as a programmer, I love working around people who program for the sake of programming, who find fun and satisfaction in writing code. I don't mean to suggest the perception of code as just one of many means to an end is wrong either; it actually makes perfect business sense. It's something managers need to understand. But in your "enlightenment" you've forgotten what made you tick in the first place - how do you translate your new business-value-driven mindset to something the people under you (who don't have that mindset) can appreciate? Hint: it's not by telling them their cool hacks are useless. And we wonder why programmers distrust management.

beat 13y ago
Avoiding writing code is quite often a "cool hack".
beat 13y ago
Actually, let me put this another way... back in the original dotcom era, I worked at a startup that decided to write a BIOS. With the amount of hardware we'd be selling, it'd save a million dollars! Well worth six man-months or so of work, right? WRONG. That was six man-months of critical programmer time when the time and money was running out, and all we learned was that we couldn't do it in a 512k PROM (not with our design anyway), and upgrading to a 1mb PROM would have cost more than a license from Phoenix for their BIOS. That's what happens when you let the inmates run the asylum. Programmers are fools, for the most part. They don't understand what problem they're really trying to solve. We thought we were solving a cost-of-production problem for a fully scaled business. That wasn't the problem. The PROBLEM was NOT DYING. And that meant getting a working product out the door as quickly as possible, even if it cost more.
- lemming 13y ago
  Programmers are fools, for the most part. They don't understand what problem they're really trying to solve. That's a little harsh. I think it's fairer to say that they often don't have insight into the wider strategic objectives of the company, and that's as much a company failing as anything. I'm now a firm believer in sharing e.g. revenue numbers with everyone in the company and explaining why they're important - people are much more willing to accept things when they understand the wider picture.
deleted 13y ago
[deleted]
mturmon 13y ago
It's not just managers vs. coders. It's also experienced coders vs. novices. You get tired of writing a pile of code that solves the problem the wrong way, so after 10 or so iterations of un-appreciated or un-used code, you learn to try to look at the big picture instead of always trying to isolate the problem into a fun programming exercise. There is a management lesson here in being sure the right people are working on the right stuff. If you may need process improvement to generate the nightly reports by the next morning, don't send someone who loves to re-implement scripts in C. Or, if you're the person who loves to re-implement scripts in C, realize that your prospects may be limited.
chaz 13y ago
> Hint: it's not by telling them their cool hacks are useless. No, of course not. It's by showing/encouraging more ways to hack a solution. Writing code is one of many tools that can be used, and as the adage goes: "if the only tool you have is a hammer, everything looks like a nail." You can't pick the best tool for the job if you only want to use one tool.

0xdeadbeefbabe 13y ago

After fiddling with gnunet for too long I'm wondering if the code you don't write will or will not solve the NSA spying problem. I'm in the will not camp so far because gnunet isn't working, and even if it connected to some peers I wouldn't know how to verify my anonimity. They also say something like you might be protected from the law if you click Y here. But I don't want a not guilty verdict, I don't even want to go to trial.

mgerals 13y ago

Strictly relying on 3rd-party code without understanding the algorithms and complexities can lead to just as many problems. In my opinion you still better be a very good coder when relying on libraries, just plug and play will fail you sooner than later. I have seen my fair share of this. When requirements slightly change and you have to adapt a library, suddenly you have to deal with 20k (or more) lines of code and have no idea where to even start. You may just need to use a tiny part of that library but the code is so tightly bundled and abstracted (for good reason) that you have to dig through layers and layers just to make a simple change. You should at least understand the complexities when relying on 3rd-party code, the Go dependency hell of the game "Haunts" comes to mind (but I don't remember the details, so probably not the best example). A few additional thoughts: 1. I said "plug and play will fail you sooner than later" -- for most startups that "later" never happens or is not of concern. How often has a startup's code-base made into an acquiring company's production systems without a complete rewrite? 2. Also, when reading some of these posts, I tend to look at the author's motivation/background. This is a somewhat controversial claim (on HN) -- so it is bound to stir up some interest/pubilicty. And also, this is probably not the worst way to court some new clients ("hey, we write less code and waste less of your money"). But I do believe that the re-use approach would be well-suited for short-lived marketing campaigns, as opposed to some other software -- think limited scope and fixed requirements. I'd do the same if I had to work on several campaigns that are probably all similar to a degree.

chn 13y ago
I think there can be good reasons to choose mature library that solves complex problem (even if you don't understand the code) instead of writing your own code. I find writing a simple wrapper around big libraries a good practice, it should limit the external library features to what you really need, give you more control on how it's used and allow to switch to other library or even write your own code with much less effort.

tsm 13y ago

Working as one of two programmers at a startup has really reinforced this for me. As a student and even when I worked at BigCo, I loved taking the time to do things myself, do things Right (with the capital R), and so forth. Now, since I'm surrounded by business people, I'm thinking more in terms of value-provided, not cool-hacks-provided. It's made me ship better things a lot faster and make more people happy. And, really, that's the end goal.

danso 13y ago

I think this is more about "feature creep" than specifically about code, though the OP's point is well taken. But the distinction matters: the dilemma I find myself facing is: do I write that extra library or test to make sure things work? Do I take the time to refactor? Is it worth the time? In those situations, it isn't at all an easy question, unless you know the problem you face requires a one-off software solution with little liability for maintenance.

cdmo 13y ago
Yes, I think the point of the story was about being business minded rather than indulging your own programming interests and prowess. Or in other words, the feature creep that you add yourself. This is advice is well timed for me ;)

captn3m0 13y ago

This is my constant advice to my startup-hungry-friends. I constantly tell them: "Coding it should be the last item on your list."

rmcastil 13y ago

I've come to a similar conclusion but I tend to think of it as solving little problems with the simplest solution possible. Don't pre optimize and don't pre abstract. This is a thought process I think you arrive at when you're running your own business or in some sort of managerial role. You start realizing the constraints (time, budget, resources, etc) involved in building software. When we first come into the world of software we just want to write awesome code. But to truly evolve as a developer you need to start asking real questions regarding what you are building. Are we making the budget bleed by spending 3 weeks on making the most beautiful piece of code possible for a feature when it was originally estimated to take two days? Can an open source library be used instead of us trying to build something from the ground up? How does this feature add real value to the users of this product?

themckman 13y ago

It gets me closer to adding value directly, instead of shoehorning my preferred solution onto a problem. But shoehorning my elaborate solution onto the problem is the funnest part. Providing value is easy and boring...

btilly 13y ago

Let me turn this around. Most feature requests arrive from a user telling you how they think you should solve some other problem. If you can figure out the real problem and solve it better, that will be an improvement over delivering the exact request as given. (If you can't solve the real problem, though, or you misunderstand it, that's worse.) For example at one company I was asked to speed up a report. The problem was that it was running too slowly and was timing out in the browser. Instead of tackling that fun optimization challenge, I built a feature that would cause any report that took more than a minute to run to be emailed to the current user. My manager said that he received more thank yous for that feature than for everything else the team had done in the previous 6 months. At another company I received a request to add a feature that would prioritize pushing specific pieces of data to the website. (We'd had some stability problems, and they had no visibility into what was happening.) I knew that adding this prioritization feature would further destabilize the data transfer logic that I was trying to make more robust, talked to my manager, and refused the request. The senior executive requesting the feature tried to get another co-worker to do it instead, that one asked me innocently how to go about it, I got him to push back. Several months later I got enough of a break from other projects to consider the prioritization feature and asked the executive whether he still needed it. His response? "It has been months since data took more than 5 minutes to get to the website, I'm fine." Also it can help to generalize your solution. At a third company I built a reporting system where instead of just plugging inputs, every form field could template the SQL that was being used. So a report could also generate drilldowns of itself, and you could combine these in a very flexible way. After a while over 2/3 of the special report requests that I got could be immediately resolved by showing that it was available if you combined two features that had been added for other users doing something else. (My turnaround time for other requests tended to be under 2 hours - and the features, documented, were available for anyone who needed them.) Programmers do not provide value by writing code. We provide value by solving problems more quickly and cheaply than the alternative. The better you solve problems, the more value you provide.

drhayes9 13y ago
That’s why it was left to wizards, who knew how to handle it safely. Not doing any magic at all was the chief task of wizards—not “not doing magic” because they couldn’t do magic, but not doing magic when they could do and didn’t. Any ignorant fool can fail to turn someone else into a frog. You have to be clever to refrain from doing it when you knew how easy it was. There were places in the world commemorating those times when wizards hadn’t been quite as clever as that, and on many of them the grass would never grow again. - Terry Pratchett

beat 13y ago

Code is not an end in itself, only a means to an end.

losethos 13y ago

I wrote all 130,000 lines myself. I hired an artist for $3000 for some work. You would be advised not to fuck with me -- God is right here and will send you to hell. God says... Foundation floating parched Ask thats_just_wrong comely guidest employ formlessness sigh -not definite so_let_it_be_done distances paper God_smack recite

salmonellaeater 13y ago

This is spot on. Every time you solve a problem without writing code, you avoid possible bugs, future maintenance, and legal issues, and you don't spend time. The second-best code, after code you avoided writing, is code you can delete and as a side effect solve a problem. The less code, the better.

j-kidd 13y ago
Those are certainly valid points, but I can't help but feel like the OP is going down a slippery slope, and will soon start contracting out coding work to 3rd party, which would then comes back full of bugs and doesn't mesh nicely with existing architecture, thus requiring full-time maintenance from internal staffs anyway.
- menacingly 13y ago
  I can see how you would have come away with that impression. We produce a lot of code, so much in fact that it didn't even occur to me to state the value in doing so. We definitely do and will continue to keep a talented team busy.

richkuo 13y ago

Every non-technical entrepreneur or co-founder needs to read this. Twice. You would not believe how many non-technical people think that programming is a critical component to the problems they are trying to solve.

QEDturtles 13y ago

This is a really cool article in that it shows the transition of one developer into an architect. I think the grief the author is taking in some of the comments has more to do with presentation than content. The weekends of clever hacks that he mentioned were essential to his development as they are for all of us. The weekend is a good time for clever hacks. If they have useful business implications all the better. Exciting, innovated packages often sprout from a developer's desire for a more elegant, stable, focused, or powerful solution for a problem or a problemset. These innovations should be abstracted into reusable packages and reused. However, in a business environment, developers need to be focused on solving problems for users. They need to do so in the most stable and sane possible manner. That means that code should be a last resort when a solution has not already been written. If you miss your weekend hackathon, contribute back to the packages that you found helpful. This way, you can get your kicks from clever new hacks and improve several of your existing projects in one fell swoop! Writing code (and lots of it) is essential to growing as a developer. Unfortunately, it's often a detriment to software projects.

Mithaldu 13y ago

It took him becoming a manager to figure out what the Programmer's Virtues* are about? * http://threevirtues.com/ http://threevirtues.com/

JDGM 13y ago

I enjoyed this but on the surface reading didn't like his "it makes me think an octave higher" line, and on reading the context from Sivers (an excellent article that, btw) I even more didn't like it. The analogy just didn't seem appropriate. However, after some thought I felt the paragraph after with the bulletpoints does actually line up quite nicely (albeit rather obliquely) with what Sivers was talking about and I think I get it now, the finer points just weren't immediately obvious. This a minor niggle but I think that he could have explained that part better, and without requiring a whole other article for context (no matter how good that article is!).

menacingly 13y ago
OP here. That's really valid feedback and I'll keep it in mind in the future.

jacob019 13y ago

This really resonates with me. I'm having a terrible time getting high quality code from my team. Software is expensive to develop, and as a tech company we always try to solve every problem with code first. I'm going to make more of an effort to think about our problems beyond the lens of code, thanks!

6d0debc071 13y ago

I don't think that too many people like the feeling that their work is going to be useless. On the other hand, if you don't have a larger overview of a problem domain it can be difficult to feel that you're making progress doing anything other than optimising and abstracting. On the other hand there are reasons why the Linux kernel runs dramatically better designed than Windows.

ams6110 13y ago
The NT kernel is well designed. Windows is full of a lot of other cruft though, a lot of which isn't.

prayag 13y ago

Sometimes you have to write software to make all the other option much more efficient. Let give an example, we at MobileWorks (https://premier.mobileworks.com https://premier.mobileworks.com) are in business of providing virtual temps to businesses. Since we are built to scale, the entire team has virtually unlimited supply of temporary labor and we use it A LOT. However, in a lot of cases a little bit of code actually makes the temps much more efficient. That's the real value of code. Making the mundane much more efficient.