11 ms·

You Don't Want to Think Like a Programmer

112 points by platz 13y ago

arocks 13y ago
I agree and disagree here. Disagree because you need to master the rules before you break them. This is surprisingly true for most skills say Cooking, Novel writing, or Sketching. Though you might think that it is best to be completely creative and unconstrained, there are written or unwritten rules in every artistic endeavour which is inherent in the medium. I agree with him that working on a project is often the best ways to learn a new skill. But for heaven sake, heed to what the experienced folk say and deliberate on whether to follow them or not.
- coldtea 13y ago
  >I agree and disagree here. Disagree because you need to master the rules before you break them. This is a truism, but I don't think it's all that applicable to everything. There are lots of musicians who paved their own way, breaking the rules, without first having "mastered" the previous ruleset. Same for painters (there are pioneer modern painters who could not paint anything Renaissance style for example). And, yes, there are programmers who created succesful software, even multi-million businesses, without really knowing the whole craft of software engineering. Isn't, for example, Derek Shivers (who frequents HN from time to time) a classic example of "fake it till you make it"? Or even this Zuckenberg guy. I don't think Facebook was the result of a master software craftsman.
  - girvo 13y ago
    Some early FB code got leaked a while back... Master software craftsman, Zuckerberg was not.
dlss 13y ago
OP says that a masterful understanding of coding in general necessarily leads to a disregard for features that users want. I think this is a false dichotomy -- developing a masterful understanding of what things cost must be coupled with a masterful understanding of what makes things valuable. If OP shared what caused him to think this thought perhaps a good conversation would happen. I could see myself write something similar about CFOs after encountering one at a past startup who kept turning the air conditioning off to the point where coding in the office was a sweaty experience. I think the title of the correct article is "You want to think like a programmer and a customer" or "You don't want to thin like a bad programmer"
- henrik_w 13y ago
  Exactly! Why would it have to be either/or, when both is what you want.
  - coldtea 13y ago
    Because humans tend to be obsessed with one or the other, humans have limited capacity, humans tend to go overboard. At the end of the day you have to learn to make compromises, and that you can't always have "both".
    - henrik_w 13y ago
      Are you saying it is not possible to both be good at programming and have a good understanding of the business? Of course there are compromises, but when you know both domains you make better compromises and trade-offs.
      - coldtea 13y ago
        >Are you saying it is not possible to both be good at programming and have a good understanding of the business? No, I'm saying that what's merely possible doesn't matter, it's whats possible AND probable that's important. That is, don't aspire to be THE exception that's excellent at both, first try to be adequate at both. This way, excellence at either or both, if it ever cames, won't have left you crippled at the other skill. Plus, it might never come anyway, in which case being adequate can get you a long way itself. Also, my dichotomy (and what the original article talks about) doesn't concern merely "being good at programming", but about being preoccupied with excellence at programming -- the perfect architecture, masterful application of design patterns etc.
        henrik_w 13y ago
        Most people I work with are well aware of why we write software. I can't think of anybody that is so preoccupied with the programming side of things that they disregard the business side. So it's simply not a problem I encounter, but maybe your experience is different.
ycmike 13y ago
As someone leaving the beginner stages and moving to intermediate development I found this to be very true and wish I did a lot less tutorials and just started to hack stuff together. I learned far more doing something crappy from scratch than 100% on some "X" clone!
bomatson 13y ago
Understanding the software of your domain will allow you to be more informed on how to improve it. A mastery of Midi to make better and new musical instruments... The foundation for these abilities comes from habits this OP encourages you to avoid
- coldtea 13y ago
  >Understanding the software of your domain will allow you to be more informed on how to improve it. Or it could result in you getting lost in its minutiae and losing the big picture. After a while you might not even care to improve it at all, just end happily exploring niche advanced areas.
jeffdavis 13y ago
It's really hard to keep moving all the way up and down the stack. If you spend a few weeks hacking on a few key low-level routines, that might enable you to write the rest of the code in python and use some library you really want. In turn, that might enable you to release many more innovations faster than you would otherwise, and create something awesome. But it's hard to remember all of that when you're in the middle of writing some C code so that it can be optimized with vectorized instructions when targeting newer chips. Hacking is great, but engineering can inspire and enable hacking. How many of these cool startups would be around without gnu/linux/freebsd? I think the trick is to go to a higher level once a day, or spend more time at a higher level once a week. What is value you will deliver to at least one other person? Are you making real progress getting there; or are you building an endless series of platforms on top of each other without ever having a clear application in mind? Even if you are working on a generic performance improvement you can still do that. If 10,000 servers are running your software, and you improve performance by 2.5%, then you can measure the value you delivered in terms of power saved per year and it would be a real accomplishment. That will be motivational, and it will also help you choose a better follow-up project to deliver even more.
- pjmlp 13y ago
  > How many of these cool startups would be around without gnu/linux/freebsd? They would be using Solaris, Aix, HP-UX, Tru64, VMS, Windows instead.
  - bluedino 13y ago
    GNU is much more than an operating system. Cheap Intel hardware has just as much to do with it as free, quality OS and programs. Remember how expensive it was to start an internet company in the 90s when you had to run Sun hardware, Oracle databases...Even developer hardware was expensive. $3,000 laptops vs today's $1,000 machines.
    - pjmlp 13y ago
      True, but you didn't need to go Sun/Oracle, there were other cheaper alternatives available.
connor 13y ago
I'd take this further and add that you should always be doing something wrong in the pursuit of more than just code. As a novice programmer you can spin your wheels learning every best practice without building much of anything. And HN often compounds this problem - look at every 'You're doing it wrong ...' post. Instead, I think you should make something crappy and make the rookie mistakes. Overtime, simply look to improve bit by bit. I imagine someone will protest this idea, saying that there's already enough crappy software out there, that the world doesn't need any more technical debt. But this fails to realize that technical debt is a good thing in someways- it's a by-product of learning and crashing through boundaries. In a way, technical debt is analogous to carbon emissions- yes, by itself it's a bad thing. But in the larger scope, carbon emissions are a by-product of industrialization, a process which has vastly improved our quality of life. Technical debt, like carbon emissions, is a sign of progress.
- bad_user 13y ago
  I once worked on a project that pivoted the business logic so many times, with one hack after another, that technical debt went through the roof - at which point it became next to impossible to further evolve it. Because of legacy and tight coupling, simple features would take longer and longer to implement. And because the architecture was completely based on assumptions of low traffic that would grow organically (it was a web service), the shit really hit the fan when we started getting tens of thousands of requests per second, again because the architecture was so bad that it seemed as any optimization we did was worthless and actually made matters worse. The web service actually had to be stopped for a while, because as a startup we couldn't afford to rent a thousand frontend servers and even if we did, you're only moving the problem up the chain, which in our case was the data storage and again, because of tight coupling, it was unfeasible to move it to something that scales horizontally. So the solution was to basically rebuild this web service from scratch. This decision also came with business logic simplifications - as we realized that certain features were unfeasible at that scale, so many features ended up being dropped based on technical considerations. Which IMHO was OK, because the best way to approach problem solving is to build less and sometimes we end up building features instead of solving the problem that we set out to solve in the first place. I wish I could say that our initial approach allowed us to iterate fast. But it didn't. I was there from the start, I've built the prototypes, I did the pivots, I made all the wrong choices, I managed the team that came after and I could've made all the right choices without sacrificing fast iterations. All it takes is experience and tools that do "the right thing" in regards to your problem, without sacrificing productivity - being able to recognize the best tool for the job, being able to simplify problems, being able to tell the cost of something - now those are traits of good software developers. The article does have a point though - you can learn all day about tools, best practices, algorithms, paradigms or whatnot, but in the end the goal isn't and shouldn't be to write "beautiful code", but rather to produce artifacts for solving problems that people have.
georgemcbay 13y ago
I agree with the basic idea but would advise most people who are in it for the long haul to still go through the process of learning to "think like a programmer", just always be prepared to reach a point where you get good enough that you can throw some of what you learned out the window some of the time, when it benefits whatever it is you are actually trying to accomplish. While some people see that middle bit where you teeter on the precipice of becoming a full blown architecture astronaut as wasted time or effort I see it as a Journeyman phase that most people need to go through to become true masters. Sort of like photographers should fully understand the rule of thirds and other classic rules of composition because really understanding them gives them better insight into when and why they are better off breaking them.
- einhverfr 13y ago
  I think the larger issue is that it is hard to learn how to use rules effectively if you haven't learned hard lessons by breaking them. Part of the problem is that human language is by nature imprecise as is human knowledge. The rules have very fuzzy edges and people need to be introspective about these sometimes. But you can't be introspective about the rules if you aren't pushing the limits. Otherwise you are in safe territory and there's nothing to be introspective about.
fsloth 13y ago
I think the problem is not that you shouldn't think things through with academic rigor. The problem is that there is so much cargo cult junk in programming as a field that it's impossible for a novice to discern the pseudo-engineering crap from the truly beneficial concepts. Beyond the core algorithms and data structures whose mastery should be kinda obligatory if you want to implement anything in production, it is impossible for a novice to tell what he should ingrain in his daily work and what he should not. The advice given here is therefore is very good. Get practical experience in building things, so you identify the beneficial abstractions when you learn of them, and have courage abandon those that do not provide value. The downside is the "expert beginner" who learns a one way to do a thing and thinks it's well and good to do it that way for all eternity. Higher level languages are fantastic because they offer efficient and practical abstractions out of the box for the "patterns" you would implement yourself in a half-assed way in a lower level language like c. People infatuated with solutions finding a problem are kinda bad from a communication point of view. They are so a plenty that when one tries to offer practical higher level solutions to existing problems the listener often thinks this is motivated out of love for the solution and not out of love for the problem.
singingfish 13y ago
> You come to understand why every time a useful program is written in Perl or PHP Mate, I agree PHP sucks (aside from the legions of maschochists who do useful stuff with it), but a lot of perl (when used in a disciplined manner in communication with ones peers) is a useful and productive orthogonal take on computer science.
fsloth 13y ago
As a counterpoint, there are very good engineering reasons for standardized code layout and enforcing const correctness. They are there to optimize the use of the mental energy of the programmer. Const correctness makes it much easier to read and reason code someone else has written. Or myself, months from now on. Standardized code layout should be strict enough that you can identify scope at a glance when browsing through a 10 MLOC engineering CAD application and hunting for that one bug or strange call path. But - these are necessary features for _production_ code. For _prototyping_ code you should optimize for maximal mutation rate and not necessarily legibility rate. Although the code should not be garbage (if you can't read it it's kinda worthless) strict conventions often hinder fast iteration and you should really figure out which ones are necessary constraints for the problem at hand and which are not.
Fasebook 13y ago
I would love to agree with this, and I do in principle, but the reality of IT technology today means we can't make such assumptions in our abstractions without knowing the implementation details to extreme degrees.
einhverfr 13y ago
I disagree with the author over software engineering vs problem domain issues. It's not that the author is wrong. It's that he doesn't articulate the role of the software engineering concerns. It isn't about whether to obsess about these. It is about when to. The ideal is to cycle. Focus on the problem domain. Get something working. Come back, look at the software engineering domain. Obsess about that for a while. Then move on to the next project. The cycle itself means you get to be productive, get to focus on solving real problems, and get a chance to evaluate your code style and experience, improving it along the way too. I have maintained 200k line Perl programs written by someone who never stopped to ponder anything outside the problem domain. It was a total mess. The program was basically a textbook in how not to program, particularly how not to write Perl. Matt Trout said it was "written by the programmer that Matt's Scripting Archive would have fired for writing bad code." If you want your software to last, then software engineering has to be an aspect of it. But the author is also right that you can't let this detract from solving the problems at hand. Consequently you have to be able to really focus on learning each side in cycles.
- fuzzix 13y ago
  > I have maintained 200k line Perl programs written by someone who never stopped to ponder anything outside the problem domain Ditto, though I think I have a unique element to my story. I spent a week deleting code I couldn't detect a use for. I nuked nearly 40,000 lines and could not discern a difference in functionality (though, couldn't be certain since I hadn't completed the test suite.) Writing a test suite for software with no spec and only others' vague recollections of meetings to go on (Agile!) is fun - it basically ends up a regression suite enforcing current broken behaviour. Perl takes no part of the blame for this, some of the Rails code needs to be seen to be believed - looked like an early PHP tutorial in places. What was great was, the Perl was full of comments about how much easier it would have been in Ruby/Rails because he never bothered to read the docs on references.
  - einhverfr 13y ago
    > I spent a week deleting code I couldn't detect a use for. I nuked nearly 40,000 lines and could not discern a difference in functionality (though, couldn't be certain since I hadn't completed the test suite.) I don't think we deleted 20k lines. Probably more like 5k. However the kicker was when deleting something that seemed harmless enough broke something. In that case, it was a comment. We're not talking about smart comments here. We are talking about comments that are parsed and used by the application at run-time for actual logic :-P. Oh, and when we added test cases for rounding numbers.... the test cases failed.... Regarding the role of language, I would much rather be maintaining bad Perl code than bad PHP code.....
jaimebuelta 13y ago
Don't we tend to discuss a lot about semantics and words? "Don't think like a programmer, think like a developer" "Learn to code, not to program" Most of the cases we have words that mean basically the same, and we almost randomly say, more or less, that X means "a good Y".
- jaredklewis 13y ago
  Agreed! I liked the OP, even though it was quite guilty of this. But what is it about programmers (hackers/coders/developers/whatever it's called in your idiolect) that makes us so pointlessly passionate about diction?
pjmlp 13y ago
Fully agree, even when I bash C and Go design decisions regularly, I wouldn't care using them if that is what customers require me to do. What matters at the end of the day is delivering working solutions to a problem, not how beautiful such solutions are.
benburton 13y ago
> Take time to line up your equal signs so things are in nice, neat columns. Anyone else have a gag reflex when they see code like this?
- delinka 13y ago
  If I've got an enum where all values require assignment, lining up the = makes it easier for my human eyes to scan names and values later.
  - benburton 13y ago
    I don't buy this argument at all. Let's start with what might be a fairly typical set of variable declarations in Javascript: var firstVar = "one"; var secondVar = "two"; var thirdVar = "three"; I think you'd be hard-pressed to find anyone that would say this is significantly more difficult to read than the lined-up alternative: var firstVar = "one"; var secondVar = "two"; var thirdVar = "three"; But, of course, variable names aren't always going to be short. You might have something like this instead: var firstVar = "one"; var secondVar = "two"; var thirdVar = "three"; var thisVarHasAReallyLongName = "four"; var thisIsAnotherVarWithALongerName = "five"; My eyes don't have any problem scanning the variable names to see what's what. I also find it very natural to scan the variables by-value to determine which value is assigned to which variable (which I believe is typically the argument for the lined-up-equals alternative). Lined up, this looks like the following: var firstVar = "one"; var secondVar = "two"; var thirdVar = "three"; var thisVarHasAReallyLongName = "four"; var thisIsAnotherVarWithALongerName = "five"; I don't know about you, but I find it significantly more difficult to visually parse these by-value to determine the variable corresponding to values "one", "two" and "three". The whitespace gap means that visually I may forget the vertical alignment of what I was looking at on the right when I try to find the variable name on the left. I also think that it's at least a little bit harder to consistently enforce a convention of this kind. If a variable name gets too long, and you're not using some sort of auto-formatting, you have to manually space-out the variables to a new name length every time you introduce a newer, longer-named variable. I think the real impulse people have for this kind of convention is that it actually just looks a little bit neater, because things are aligned in columns. In reality I think it's much more difficult to parse and maintain.
tick113 13y ago
It sounds like a strong parallel with people who like to talk about doing great things, and people who actually do things.
mimog 13y ago
If you make your living as a programmer you most certainly want to be thinking like one. Those patterns, best-practices, design principles, preference for static typing etc. all matter when you are paid to develop systems that perform well, are easy to maintain, have few bugs and are delivered on time. If however you are not burdened by such obligations, by all means, go full cowboy.
kh_hk 13y ago
I think the article stretches too far away the "think like a programmer" motto by including design patterns and TDD in there. You will have trouble learning if you do not think like a programmer, as in basic CS 101. Thinking like a programmer is really near to mathematical thinking, just the basic stuff: logic, invariants and program correctness, in paper, and using pseudo-code. After a year one will be ready to throw that stuff through the window, not because it is not useful, but because it is already engraved on your brain and somehow, even if you do not use assertions at the start of your functions or do not write an invariant down for each loop, it will be there and will make your code cleaner and free of copy-pasted code.
- marktangotango 13y ago
  >>Thinking like a programmer is really near to mathematical thinking Some people say that but I've never understood it myself. To me, programming is nothing like mathematical thinking, especially at an intro level. It's more about giving super precise instructions to a stupid machine that has to be told every little thing. There are lots and lots of successful, competent programmer who don't know much math or logic as academic fields. Edit; maybe a more relevant discussion would be talk about what is meant by 'mathematical thinking'.
  - rprospero 13y ago
    I would argue that giving many super precise instructions is exactly an example of mathematical thinking. It's like the old algebra problem of "Prove 23=6". It's blatantly obvious to everyone over the age of two, but the proof is quite long and tedious. 2*3=(1+1)*3 | Definition of 2 2*3=1*3+1*3 | Distributive property 2*3=3+1*3 | Identity of Multiplication 2*3=3+3 | Identity of Multiplication 2*3=3+(2+1) | Definition of 3 2*3=3+(1+2) | Commutativity of Addition 2*3=3+1+2 | Associativity of Addition 2*3=(3+1)+2 | Associativity of Addition 2*3=4+2 | Associativity of Addition 2*3=4+(1+1) | Definition of 2 2*3=4+1+1 | Associativity of Addition 2*3=(4+1)+1 | Associativity of Addition 2*3=5+1 | Definition of 5 2*3=6 | Definition of 6 It's the exact same set of logical skills to take a fixed set of tools and see how those tools can take you from where you are to where you want to be. It's not that programmers need Category Theory and Partial Differential Equations (however fun and useful they can be), but rather that someone who can't prove that 23=6 probably can't code.
dutchbrit 13y ago
Related: I once had a girl in my bed and I'd done so much programming that day that I started to think of her in code whilst half asleep... Didn't make any sense at all...
dromidas 13y ago
While the article does make a good point... I find it happens very rarely. Or if it does its almost never vocalized. It's a little like saying don't think like an English speaker or you're going to pedantically correct everything. Sure it happens, but it's not a lot of people that do it and among those its 1 in a million that actually do it to a point where it gets in their own way.

112 points by platz 13y ago

I agree and disagree here. Disagree because you need to master the rules before you break them. This is surprisingly true for most skills say Cooking, Novel writing, or Sketching. Though you might think that it is best to be completely creative and unconstrained, there are written or unwritten rules in every artistic endeavour which is inherent in the medium. I agree with him that working on a project is often the best ways to learn a new skill. But for heaven sake, heed to what the experienced folk say and deliberate on whether to follow them or not.

coldtea 13y ago
>I agree and disagree here. Disagree because you need to master the rules before you break them. This is a truism, but I don't think it's all that applicable to everything. There are lots of musicians who paved their own way, breaking the rules, without first having "mastered" the previous ruleset. Same for painters (there are pioneer modern painters who could not paint anything Renaissance style for example). And, yes, there are programmers who created succesful software, even multi-million businesses, without really knowing the whole craft of software engineering. Isn't, for example, Derek Shivers (who frequents HN from time to time) a classic example of "fake it till you make it"? Or even this Zuckenberg guy. I don't think Facebook was the result of a master software craftsman.
- girvo 13y ago
  Some early FB code got leaked a while back... Master software craftsman, Zuckerberg was not.

dlss 13y ago

OP says that a masterful understanding of coding in general necessarily leads to a disregard for features that users want. I think this is a false dichotomy -- developing a masterful understanding of what things cost must be coupled with a masterful understanding of what makes things valuable. If OP shared what caused him to think this thought perhaps a good conversation would happen. I could see myself write something similar about CFOs after encountering one at a past startup who kept turning the air conditioning off to the point where coding in the office was a sweaty experience. I think the title of the correct article is "You want to think like a programmer and a customer" or "You don't want to thin like a bad programmer"

henrik_w 13y ago
Exactly! Why would it have to be either/or, when both is what you want.
- coldtea 13y ago
  Because humans tend to be obsessed with one or the other, humans have limited capacity, humans tend to go overboard. At the end of the day you have to learn to make compromises, and that you can't always have "both".
  - henrik_w 13y ago
    Are you saying it is not possible to both be good at programming and have a good understanding of the business? Of course there are compromises, but when you know both domains you make better compromises and trade-offs.
    - coldtea 13y ago
      >Are you saying it is not possible to both be good at programming and have a good understanding of the business? No, I'm saying that what's merely possible doesn't matter, it's whats possible AND probable that's important. That is, don't aspire to be THE exception that's excellent at both, first try to be adequate at both. This way, excellence at either or both, if it ever cames, won't have left you crippled at the other skill. Plus, it might never come anyway, in which case being adequate can get you a long way itself. Also, my dichotomy (and what the original article talks about) doesn't concern merely "being good at programming", but about being preoccupied with excellence at programming -- the perfect architecture, masterful application of design patterns etc.
      - henrik_w 13y ago
        Most people I work with are well aware of why we write software. I can't think of anybody that is so preoccupied with the programming side of things that they disregard the business side. So it's simply not a problem I encounter, but maybe your experience is different.

ycmike 13y ago

As someone leaving the beginner stages and moving to intermediate development I found this to be very true and wish I did a lot less tutorials and just started to hack stuff together. I learned far more doing something crappy from scratch than 100% on some "X" clone!

bomatson 13y ago

Understanding the software of your domain will allow you to be more informed on how to improve it. A mastery of Midi to make better and new musical instruments... The foundation for these abilities comes from habits this OP encourages you to avoid

coldtea 13y ago
>Understanding the software of your domain will allow you to be more informed on how to improve it. Or it could result in you getting lost in its minutiae and losing the big picture. After a while you might not even care to improve it at all, just end happily exploring niche advanced areas.

jeffdavis 13y ago

It's really hard to keep moving all the way up and down the stack. If you spend a few weeks hacking on a few key low-level routines, that might enable you to write the rest of the code in python and use some library you really want. In turn, that might enable you to release many more innovations faster than you would otherwise, and create something awesome. But it's hard to remember all of that when you're in the middle of writing some C code so that it can be optimized with vectorized instructions when targeting newer chips. Hacking is great, but engineering can inspire and enable hacking. How many of these cool startups would be around without gnu/linux/freebsd? I think the trick is to go to a higher level once a day, or spend more time at a higher level once a week. What is value you will deliver to at least one other person? Are you making real progress getting there; or are you building an endless series of platforms on top of each other without ever having a clear application in mind? Even if you are working on a generic performance improvement you can still do that. If 10,000 servers are running your software, and you improve performance by 2.5%, then you can measure the value you delivered in terms of power saved per year and it would be a real accomplishment. That will be motivational, and it will also help you choose a better follow-up project to deliver even more.

pjmlp 13y ago
> How many of these cool startups would be around without gnu/linux/freebsd? They would be using Solaris, Aix, HP-UX, Tru64, VMS, Windows instead.
- bluedino 13y ago
  GNU is much more than an operating system. Cheap Intel hardware has just as much to do with it as free, quality OS and programs. Remember how expensive it was to start an internet company in the 90s when you had to run Sun hardware, Oracle databases...Even developer hardware was expensive. $3,000 laptops vs today's $1,000 machines.
  - pjmlp 13y ago
    True, but you didn't need to go Sun/Oracle, there were other cheaper alternatives available.

connor 13y ago

I'd take this further and add that you should always be doing something wrong in the pursuit of more than just code. As a novice programmer you can spin your wheels learning every best practice without building much of anything. And HN often compounds this problem - look at every 'You're doing it wrong ...' post. Instead, I think you should make something crappy and make the rookie mistakes. Overtime, simply look to improve bit by bit. I imagine someone will protest this idea, saying that there's already enough crappy software out there, that the world doesn't need any more technical debt. But this fails to realize that technical debt is a good thing in someways- it's a by-product of learning and crashing through boundaries. In a way, technical debt is analogous to carbon emissions- yes, by itself it's a bad thing. But in the larger scope, carbon emissions are a by-product of industrialization, a process which has vastly improved our quality of life. Technical debt, like carbon emissions, is a sign of progress.

bad_user 13y ago
I once worked on a project that pivoted the business logic so many times, with one hack after another, that technical debt went through the roof - at which point it became next to impossible to further evolve it. Because of legacy and tight coupling, simple features would take longer and longer to implement. And because the architecture was completely based on assumptions of low traffic that would grow organically (it was a web service), the shit really hit the fan when we started getting tens of thousands of requests per second, again because the architecture was so bad that it seemed as any optimization we did was worthless and actually made matters worse. The web service actually had to be stopped for a while, because as a startup we couldn't afford to rent a thousand frontend servers and even if we did, you're only moving the problem up the chain, which in our case was the data storage and again, because of tight coupling, it was unfeasible to move it to something that scales horizontally. So the solution was to basically rebuild this web service from scratch. This decision also came with business logic simplifications - as we realized that certain features were unfeasible at that scale, so many features ended up being dropped based on technical considerations. Which IMHO was OK, because the best way to approach problem solving is to build less and sometimes we end up building features instead of solving the problem that we set out to solve in the first place. I wish I could say that our initial approach allowed us to iterate fast. But it didn't. I was there from the start, I've built the prototypes, I did the pivots, I made all the wrong choices, I managed the team that came after and I could've made all the right choices without sacrificing fast iterations. All it takes is experience and tools that do "the right thing" in regards to your problem, without sacrificing productivity - being able to recognize the best tool for the job, being able to simplify problems, being able to tell the cost of something - now those are traits of good software developers. The article does have a point though - you can learn all day about tools, best practices, algorithms, paradigms or whatnot, but in the end the goal isn't and shouldn't be to write "beautiful code", but rather to produce artifacts for solving problems that people have.

georgemcbay 13y ago

I agree with the basic idea but would advise most people who are in it for the long haul to still go through the process of learning to "think like a programmer", just always be prepared to reach a point where you get good enough that you can throw some of what you learned out the window some of the time, when it benefits whatever it is you are actually trying to accomplish. While some people see that middle bit where you teeter on the precipice of becoming a full blown architecture astronaut as wasted time or effort I see it as a Journeyman phase that most people need to go through to become true masters. Sort of like photographers should fully understand the rule of thirds and other classic rules of composition because really understanding them gives them better insight into when and why they are better off breaking them.

einhverfr 13y ago
I think the larger issue is that it is hard to learn how to use rules effectively if you haven't learned hard lessons by breaking them. Part of the problem is that human language is by nature imprecise as is human knowledge. The rules have very fuzzy edges and people need to be introspective about these sometimes. But you can't be introspective about the rules if you aren't pushing the limits. Otherwise you are in safe territory and there's nothing to be introspective about.

fsloth 13y ago

I think the problem is not that you shouldn't think things through with academic rigor. The problem is that there is so much cargo cult junk in programming as a field that it's impossible for a novice to discern the pseudo-engineering crap from the truly beneficial concepts. Beyond the core algorithms and data structures whose mastery should be kinda obligatory if you want to implement anything in production, it is impossible for a novice to tell what he should ingrain in his daily work and what he should not. The advice given here is therefore is very good. Get practical experience in building things, so you identify the beneficial abstractions when you learn of them, and have courage abandon those that do not provide value. The downside is the "expert beginner" who learns a one way to do a thing and thinks it's well and good to do it that way for all eternity. Higher level languages are fantastic because they offer efficient and practical abstractions out of the box for the "patterns" you would implement yourself in a half-assed way in a lower level language like c. People infatuated with solutions finding a problem are kinda bad from a communication point of view. They are so a plenty that when one tries to offer practical higher level solutions to existing problems the listener often thinks this is motivated out of love for the solution and not out of love for the problem.

singingfish 13y ago

> You come to understand why every time a useful program is written in Perl or PHP Mate, I agree PHP sucks (aside from the legions of maschochists who do useful stuff with it), but a lot of perl (when used in a disciplined manner in communication with ones peers) is a useful and productive orthogonal take on computer science.

fsloth 13y ago

As a counterpoint, there are very good engineering reasons for standardized code layout and enforcing const correctness. They are there to optimize the use of the mental energy of the programmer. Const correctness makes it much easier to read and reason code someone else has written. Or myself, months from now on. Standardized code layout should be strict enough that you can identify scope at a glance when browsing through a 10 MLOC engineering CAD application and hunting for that one bug or strange call path. But - these are necessary features for _production_ code. For _prototyping_ code you should optimize for maximal mutation rate and not necessarily legibility rate. Although the code should not be garbage (if you can't read it it's kinda worthless) strict conventions often hinder fast iteration and you should really figure out which ones are necessary constraints for the problem at hand and which are not.

Fasebook 13y ago

I would love to agree with this, and I do in principle, but the reality of IT technology today means we can't make such assumptions in our abstractions without knowing the implementation details to extreme degrees.

einhverfr 13y ago

I disagree with the author over software engineering vs problem domain issues. It's not that the author is wrong. It's that he doesn't articulate the role of the software engineering concerns. It isn't about whether to obsess about these. It is about when to. The ideal is to cycle. Focus on the problem domain. Get something working. Come back, look at the software engineering domain. Obsess about that for a while. Then move on to the next project. The cycle itself means you get to be productive, get to focus on solving real problems, and get a chance to evaluate your code style and experience, improving it along the way too. I have maintained 200k line Perl programs written by someone who never stopped to ponder anything outside the problem domain. It was a total mess. The program was basically a textbook in how not to program, particularly how not to write Perl. Matt Trout said it was "written by the programmer that Matt's Scripting Archive would have fired for writing bad code." If you want your software to last, then software engineering has to be an aspect of it. But the author is also right that you can't let this detract from solving the problems at hand. Consequently you have to be able to really focus on learning each side in cycles.

fuzzix 13y ago
> I have maintained 200k line Perl programs written by someone who never stopped to ponder anything outside the problem domain Ditto, though I think I have a unique element to my story. I spent a week deleting code I couldn't detect a use for. I nuked nearly 40,000 lines and could not discern a difference in functionality (though, couldn't be certain since I hadn't completed the test suite.) Writing a test suite for software with no spec and only others' vague recollections of meetings to go on (Agile!) is fun - it basically ends up a regression suite enforcing current broken behaviour. Perl takes no part of the blame for this, some of the Rails code needs to be seen to be believed - looked like an early PHP tutorial in places. What was great was, the Perl was full of comments about how much easier it would have been in Ruby/Rails because he never bothered to read the docs on references.
- einhverfr 13y ago
  > I spent a week deleting code I couldn't detect a use for. I nuked nearly 40,000 lines and could not discern a difference in functionality (though, couldn't be certain since I hadn't completed the test suite.) I don't think we deleted 20k lines. Probably more like 5k. However the kicker was when deleting something that seemed harmless enough broke something. In that case, it was a comment. We're not talking about smart comments here. We are talking about comments that are parsed and used by the application at run-time for actual logic :-P. Oh, and when we added test cases for rounding numbers.... the test cases failed.... Regarding the role of language, I would much rather be maintaining bad Perl code than bad PHP code.....

jaimebuelta 13y ago

Don't we tend to discuss a lot about semantics and words? "Don't think like a programmer, think like a developer" "Learn to code, not to program" Most of the cases we have words that mean basically the same, and we almost randomly say, more or less, that X means "a good Y".

jaredklewis 13y ago
Agreed! I liked the OP, even though it was quite guilty of this. But what is it about programmers (hackers/coders/developers/whatever it's called in your idiolect) that makes us so pointlessly passionate about diction?

pjmlp 13y ago

Fully agree, even when I bash C and Go design decisions regularly, I wouldn't care using them if that is what customers require me to do. What matters at the end of the day is delivering working solutions to a problem, not how beautiful such solutions are.

benburton 13y ago

> Take time to line up your equal signs so things are in nice, neat columns. Anyone else have a gag reflex when they see code like this?

delinka 13y ago
If I've got an enum where all values require assignment, lining up the = makes it easier for my human eyes to scan names and values later.
- benburton 13y ago
  I don't buy this argument at all. Let's start with what might be a fairly typical set of variable declarations in Javascript: var firstVar = "one"; var secondVar = "two"; var thirdVar = "three"; I think you'd be hard-pressed to find anyone that would say this is significantly more difficult to read than the lined-up alternative: var firstVar = "one"; var secondVar = "two"; var thirdVar = "three"; But, of course, variable names aren't always going to be short. You might have something like this instead: var firstVar = "one"; var secondVar = "two"; var thirdVar = "three"; var thisVarHasAReallyLongName = "four"; var thisIsAnotherVarWithALongerName = "five"; My eyes don't have any problem scanning the variable names to see what's what. I also find it very natural to scan the variables by-value to determine which value is assigned to which variable (which I believe is typically the argument for the lined-up-equals alternative). Lined up, this looks like the following: var firstVar = "one"; var secondVar = "two"; var thirdVar = "three"; var thisVarHasAReallyLongName = "four"; var thisIsAnotherVarWithALongerName = "five"; I don't know about you, but I find it significantly more difficult to visually parse these by-value to determine the variable corresponding to values "one", "two" and "three". The whitespace gap means that visually I may forget the vertical alignment of what I was looking at on the right when I try to find the variable name on the left. I also think that it's at least a little bit harder to consistently enforce a convention of this kind. If a variable name gets too long, and you're not using some sort of auto-formatting, you have to manually space-out the variables to a new name length every time you introduce a newer, longer-named variable. I think the real impulse people have for this kind of convention is that it actually just looks a little bit neater, because things are aligned in columns. In reality I think it's much more difficult to parse and maintain.

tick113 13y ago

It sounds like a strong parallel with people who like to talk about doing great things, and people who actually do things.

mimog 13y ago

If you make your living as a programmer you most certainly want to be thinking like one. Those patterns, best-practices, design principles, preference for static typing etc. all matter when you are paid to develop systems that perform well, are easy to maintain, have few bugs and are delivered on time. If however you are not burdened by such obligations, by all means, go full cowboy.

kh_hk 13y ago

I think the article stretches too far away the "think like a programmer" motto by including design patterns and TDD in there. You will have trouble learning if you do not think like a programmer, as in basic CS 101. Thinking like a programmer is really near to mathematical thinking, just the basic stuff: logic, invariants and program correctness, in paper, and using pseudo-code. After a year one will be ready to throw that stuff through the window, not because it is not useful, but because it is already engraved on your brain and somehow, even if you do not use assertions at the start of your functions or do not write an invariant down for each loop, it will be there and will make your code cleaner and free of copy-pasted code.

marktangotango 13y ago
>>Thinking like a programmer is really near to mathematical thinking Some people say that but I've never understood it myself. To me, programming is nothing like mathematical thinking, especially at an intro level. It's more about giving super precise instructions to a stupid machine that has to be told every little thing. There are lots and lots of successful, competent programmer who don't know much math or logic as academic fields. Edit; maybe a more relevant discussion would be talk about what is meant by 'mathematical thinking'.
- rprospero 13y ago
  I would argue that giving many super precise instructions is exactly an example of mathematical thinking. It's like the old algebra problem of "Prove 23=6". It's blatantly obvious to everyone over the age of two, but the proof is quite long and tedious. 2*3=(1+1)*3 | Definition of 2 2*3=1*3+1*3 | Distributive property 2*3=3+1*3 | Identity of Multiplication 2*3=3+3 | Identity of Multiplication 2*3=3+(2+1) | Definition of 3 2*3=3+(1+2) | Commutativity of Addition 2*3=3+1+2 | Associativity of Addition 2*3=(3+1)+2 | Associativity of Addition 2*3=4+2 | Associativity of Addition 2*3=4+(1+1) | Definition of 2 2*3=4+1+1 | Associativity of Addition 2*3=(4+1)+1 | Associativity of Addition 2*3=5+1 | Definition of 5 2*3=6 | Definition of 6 It's the exact same set of logical skills to take a fixed set of tools and see how those tools can take you from where you are to where you want to be. It's not that programmers need Category Theory and Partial Differential Equations (however fun and useful they can be), but rather that someone who can't prove that 23=6 probably can't code.

dutchbrit 13y ago

Related: I once had a girl in my bed and I'd done so much programming that day that I started to think of her in code whilst half asleep... Didn't make any sense at all...

dromidas 13y ago

While the article does make a good point... I find it happens very rarely. Or if it does its almost never vocalized. It's a little like saying don't think like an English speaker or you're going to pedantically correct everything. Sure it happens, but it's not a lot of people that do it and among those its 1 in a million that actually do it to a point where it gets in their own way.