The author of that piece quotes EWD, but not in full, which is odd -- were he to have done so, it would have strengthened his thesis, viz.:
"Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better."
The strive for simplicity is very old in the hard sciences. It’s already displayed in Euclid’s elements.
Every generation rediscovers a virtue of the previous ones.
"Almost anything in software can be implemented, sold, and even used given enough determination. There is nothing a mere scientist can say that will stand against the flood of a hundred million dollars. But there is one quality that cannot be purchased in this way - and that is reliability. The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay."
> This programming bible earned a famous comment from Bill Gates: "It took incredible discipline, and several months, for me to read it."
I know he's a trillionaire and all and probably smarter than me but still - as somebody who spent a full three years reading and working through the problems in the first three books, I wonder how deep an understanding he could really have walked away with after just a few months.
I took Math 55. There is no way any of my fellow students (or anyone else for that matter) could meaningfully work through the full Art of Computer Programming (or even one of the volumes) in “several months”, even working on it full time, except in some similar way to my grandfather “seeing all the art” in the Louvre in a few hours.
I did a google search of Art of Computer Programming and see a ton of math problems. I was expecting more along the lines of actual code like assembly or machine code or something . Like actual code. How is summing an infinite series supposed to help me code better (summing the series is much easier, ill grant you that..combining ajax +css+php is hard )
I probably won't be as good at explaining as others but I will try. I think the books are like a synthesis of the art, and not designed for the teaching of the regular guy. He has a book to help approach the math called concrete math. Anyway the books start from nearly bare knowledge where the reader creates MMIX a reduced instruction set he made for the books I think, which he uses in the rest of the book to illustrate how machine level works. Anyway he has spent his life working on these and they cover the breadth of general things like algorithmic knowledge. Sorry if I got things wrong
It is a math heavy set, but as you go further on, there is more programming - but still nothing like the programming that you and I would do. He's focused on hyper-optimizing sorting routines, random number generators, hashmaps, and high-precision arithmetic. It's actually really fascinating stuff, and the sort of thing you just don't really see anywhere else (for example, did you know you can actually test the randomness of a random number generator?) But yes, he's more focused on the math behind computer science than the programming itself; besides his elevator simulator, I think the longest program in the entire first three volumes was his AVL tree implementation, which is still something that most of us encounter in data structures 101 nowadays.
Summary: « the skills required of professional and successful programmers are drastically different from the ones needed back in the 1990s. The profession now requires less mathematics and algorithms and instead emphasizes more skills under the umbrella term "sociotech." »
<author> is founder and CEO of software engineering and management platform <blah>.
So, I can expect this generation's CASE tool that magically generates all the optimized code from requirements given to this years priestho..... SocioTech Specialist?
I think their case for advancement of development technologies or how much social interaction was needed in the 90's is a bit flawed.
Having worked in corporate IT, with all its human and technical challenges, i agree that the "sociotech" elements are critical for engineering, but I also think that corporates massively misunderstand the value of the hacker culture and underestimate the extent to which the "sociotech" challenges are a direct result of having a weak "hacker" culture... we should challenge the "band aid" approach to fixing corporate bullshit
Agreed but due to the dynamic interplay between the two, balancing them well, as leaders must do, takes both high EQ/empathy, and enough tech background to be credible. (Even if that tech background is working as a non dev in technical teams)
Based purely on my personal experiences, leaders who have both boxes ticked are even more unicorn-y than the fabled 10x engineer.
> Programmers do not need to write much code anymore; all they need to do in most cases is wire together already available components.
As if this stops you from re-inventing the wheel in attempt to understand more. Understanding things is what distinguishes programmers.
I had exactly the same discussion with one of my friends that wants to become a programmer. His argument was that programming is not fun at all because all we do is use libraries and frameworks. My counter-argument was the paragraph above.
Most days I feel more like a combination of a preschool teacher and a switchboard operator than a computer scientist.
I'm not really sure how your first paragraph is a counter-argument to your friend. Reinventing the wheel to learn is just busywork. Reinventing the wheel because you need the wheel and don't have one available is fun.
Let's agree that re-inventing the wheel makes one more experienced, and also that it helps understanding things better. I believe that this distinction is what makes one a good/true programmer, compared to just lego play.
Edit: Also, I disagree that re-inventing the wheel is just busywork. Compare a programmer that just uses .sort() and another one that uses .sort() and implemented his own sort (disregarding the fact that he is not using his own sort) and really understands the math behind it. Which one would you rely on?
I would tell your friend that programming best occurs at the appropriate level of abstraction to succinctly express the problem at hand.
For example, if you are trying to write "business logic", you don't want to have to worry about allocating memory or ensuring data consistency. You just want to worry about business concerns.
I suspect your friend has simply not tried any sufficiently difficult programming project. If your problem is non-trivial, you feel appropriately grateful for libraries that provide higher layers of abstraction.
> Programmers have to know how to write maintainable code...
He implies that this somehow falls into “socitech” ability, which it is not. Maintainable code is precise, well-factored code — almost pedantic — which requires an orthogonal (if not counterpointed) talent to the more “social” talents. I would go further to say that a mathematical understanding or at least inclination is required to write maintainable code. (In the sense that the same is required to write a readable academic paper.)
Another assumption he seems to make here is that somehow there are all these algorithmic hackers who sit and write algorithms all day. No, I doubt this has been some kind of norm ever. Most of what we (business software) programmers write is business logic and data processing with an occasional, infrequent need — but need nevertheless — to break out a unique algorithm.
You can scale up all you want and into the future but we are always going to need to understand the difference between a O(n^2) and O(n) algorithm.
I’m sick of these kinds of pieces that are pure philistinism. The future isn’t going to save you from your lack of technical skills, education and awareness. Stay curious and develop yourself — your social self as much as your craft and profession.
uh... no. Not that there aren't mathematics found within writing, but that argument is irrelevant to this evaluation of taking a mathmatical, formulaic approach to code vs. one that is descriptive, and caters to the ignorances and shortcomings of the human reader.
Serious question: How much writing have you done? I'm not at all talking about writing about mathematics. I'm talking about the structure of good writing, from fiction to blog writing and everything in between--all of which, when done well, require economy, form, structure and order. Talking to many writers -- from successful screenwriters to blog writers, I find the same theme: a very deliberate awareness of the mathematical structure of their work when that work is finally "working".
I think mathematical people tend to think that code that looks like math is clean code.
Since it's similar to math, it's as clear as it can be. Like functional programming - the cleanest code is one line of code which expresses the intent as an mathematical function.
I think about defining the "maintainability" of code as a reduction in the amount of time that will be spent working on that code in the future. Therefore, there are two broad categories of maintainability fixes:
1. To reduce the number of changes that will need to be made to it.
2. To reduce the time it takes to make each change.
The (1) category encompasses the idea of making code that requires few changes. Such code is essentially "right" to begin with. I think about this mostly in terms of models -- i.e. does it accurately model the problem -- and quality -- i.e. does it have bugs or performance issues. Of course there are other concerns as well, but those are two big ones and they often involve thinking like a "computer scientist."
The (2) category -- reducing the effort of changes -- is achieved by using appropriate abstraction layers, encapsulation, low coupling, and other good-program design. There are many technical concerns in this category, but it seems there are some social ones as well.
I would say the programmer's experience is another huge factor. To sum it up in a phrase, perhaps "writing maintainable code is an act of prediction."
It is a bit hard to know what exactly he means by "socitech", but I don't think it the same as what you mean by "social". Things like writing maintainable code isn't provable, but something requires subjective considerations. Most of that knowledge doesn't come from math, but areas like systems thinking. Which is more towards social sciences.
They have to know how to get help outside of an office or even a project team when working remotely and alone. Aside from Stack Overflow, which dominates the Q&A platform for programming market, there are documentation and code repositories that a professional programmer must know how to navigate. Those who previously only relied on colleagues and friends will now lose to those who know how to learn from the entire Internet.
Wouldn't programmers know how to code it themselves without req. Stack Overflow? I would be pissed spending $100k /year on programmer who uses Stack Overflow.
I have done both. It's valuable if you are a novice and need help creating a loop or an event or something like that. If I'm paying then I'm assuming you know how to do those things. Would google hire a coder who uses Stack Overflow instead of knowing how to code without it? I cannot imagine a JavaScript coder who works for Google needing Stack Overflow for JavaScript problems.
It's unreasonable to expect people to retain knowledge of every little corner of a programming language when there's an easily available reference they could use instead.
"How often they need to refer to reference material" is a pretty terrible metric for measuring the abilities of a programmer.
Its not an unreasonable metric, if a round trip through Stack Overflow is in your thought loop then you will be significantly more limited than someone who doesn't need that. If you are doing something very obscure then its reasonable, but most programmers don't do obscure things on a daily basis.
Its similar to being unable to do math in your head. You can get away with always using the calculator but you'll be outperformed by someone who can do it without dropping their pencil.
This is somewhat similar to the reasoning that leads people to use tiling window managers. It's more efficient than a traditional window manager so they think it makes them more productive.
They're not wrong about the first part. Tiling window managers are very efficient. They are wrong about that making them more productive, though. It certainly makes them feel more productive, but this kind of micro-optimization is solving something that wasn't actually a huge productivity problem to begin with. You can add up all the time I spend switching windows in a slightly suboptimal manner on Gnome or Windows and all of that time will be lost by an extra 5 minute coffee break or the mental deficit from sleeping less than 8ish hours a night.
Similarly, a person who doesn't have to look at Stack Overflow may seem more productive, but the tiny amount of time it takes to look something up instead of remembering it is a very, very small part of the developers day. Even if they have to do it 100 times a day it's unlikely to make any meaningful difference in the big picture.
Not needing documentation would be helpful in a world where a programmer sat down and didn't stop typing for 8 hours, but that's not the world that we live in.
How long would you estimate it takes to search your question, find the result and read the answer? I think it's optimistic to think it can be done in a minute if you actually time it.
100*1 minute is an hour and 40 minutes. That is not a trivial portion of the work day. Even if it were 30 seconds that's still almost an hour.
If that is truly a micro optimization then I shudder to think of the waste elsewhere.
The question was likely whether Stack Overflow was a requirement for coding.
Suppose candidate A tends to communicate in terms of specs and reference implementations. Candidate B tends to communicate in terms of accepted answers and discussions on Stack Overflow.
All other things being equal that should be an easy choice.
It's a shame you were so downvoted. I can call several occasions watching 90% of the software developers walk out of the office if the internet went down. Many of whom had jobs not involved with maintaining or developing remote hardware.
I have also seen entire teams that would not really notice if the internet was working.
Stack Overflow has a place in productive development, but I agree - people should be able to function without it.
From a quick scan of your comments on this page, if Donald Knuth came in for a job interview at your office you would 1) encourage him to spend less time on algorithms and more time learning "hard" stuff like ajax+css+php. 2) offer him $90k if he passed the rest of the interview. 3) fire him on his first day if he googled anything.
TFA's major argument is coders are really just library stringertogetherers these days so your example programmer would be required to memorize the documentation for every dependency in order to pass muster by your standard.
Stack Overflow is an excellent resource for developers of all skills levels. I would break it down into four categories of usage:
1) Posting general questions about "coding", like syntax questions, ie- "how do you create a loop in JavaScript"
2) Posting specific, targeted questions about specifics of something the dev doesn't do on a regular basis, ie- "how do you use Google OAuth for logins"
3) Searching existing SO posts for general questions about "coding", ie- Google search for "what is the difference between let and var in JavaScript", read first SO result
4) Searching existing SO posts for the specifics, ie- Google search for "how to manage cross-tab communication using javascript", read first SO result
I would argue that a competent dev would (and should!) utilize SO using the 4th strategy on a regular basis (maybe weekly for a web dev) and occasionally the 2nd when all other resources have been exhausted. If you are paying someone $100k, yeah I agree that the first usage pattern is inappropriate, but saying "a developer shouldn't need to use StackOverflow" is a gross oversimplification of the vast knowledge that exists in SO.
3x salary inflation would mean $240k. This says it's only $90k:
The average salary for a Programmer is $89,128 in San Francisco, CA. Salaries estimates are based on 238 salaries submitted anonymously to Glassdoor by Programmer employees in San Francisco, CA....
The term Programmer is typically used to represent a much lower-status, lower-paid view of the work than Software Engineer. Check Glassdoor - it’s a pretty substantial salary difference.
Confused by the downvotes. Programmer: $89k. Software Engineer: $137k.
Even here in Toronto I know many making that much or far more. Core framework devs make about $500k a year and AI devs with AI PhD's from good schools are in the seven figures per year.
Yes - 220-250k is average total compensation for a senior in the bigcos in SF. Upwards to $500k+/y is not unheard of either... the variance is pretty crazy
There is a dichotomy in tech between makers and takers. Some people try to be a maker or a few years and can't do it for a number of reasons. There is a common set of flawed thinking that causes them to decide that programming is dead. One, their world view is different because they might have more wealth and have decided that there is an infinite pool of makers to exploit. This is obviously flawed. Companies go for years without finding the right person. When they do find someone, the person they settle on is often a faker. Two, they think robots build the constituent components that go into systems. Those memory chips are made by actual people. Just because they are 300x cheaper does not mean that it is unimportant to know how they work. Three, the status quo is the end state of technology and now is the exploitation phase where we use tech instead of make tech. Fourth, they think everything is done for cash money instead of building capabilities.
This guy also seems to think programmers are so mentally deficient they are unable communicate with the 'open source community' and that this is in some way how programmers discover new technologies. He also thinks people did not contribute code in the 1990s. Where did all this software come from? Typical business view of open source. Originally b-schools actually lectured that open source was anti-business like a trade union. Now I guess they think it is sort of a crutch for too-dumb-to-breathe programmers?
There are tons of people like this guy in tech. Coded a year or two and found out the were a taker and not a maker. Still pretending to be a maker though. Their idealized programmer befits a corporation. Colors in the lines and writes "perfect code" which has no meaning other than has been annointed by CR's as to make it seem owned by the company rather than the individual. Their ideal programmer is someone who doesn't need to understand the details, works as a unit in a team, and gathers all of their knowledge by "getting help" from the company. It is absolutely blasphemy in the corporate world to suggest that anyone synthesize his or her own ideas. That's of course ridiculous but in a business setting, the takers absolutely must discount creative thought of employees 100% which literally the "product" up for grabs in tech companies. Obviously if people knew the value and how to exploit their own original ideas they wouldn't need the fucking company or takers.
As far as math and algorithms, those are more important than ever. The reason you don't see people working on those is that those people are hidden from public and private view, jealously guarded by the takers who think they control them. Natural sciences did not fucking change since the 90's. A surface to air missile or high frequency trading algorithm or advanced simulation is as costly and valuable as ever. It's the author perception of what is valuable that has changed. He's looking for code monkeys to exploit who will "get help" and write "clean code" whatever the hell that means.
The author repeatedly cites the availability of cheaper hardware as some sort of savior of modern programming but fails to mention that the volume of data and the real-time demands of modern products were not present for many older systems that ran on more expensive hardware.
Volumen of data of course increased, but how much of that increase does actually account for "growth" and not just "inefficiency bloat" as a result of cheap hardware resources?
"Website obesity" [0] is a phenomenon where this is especially evident.
No mention here yet so I'll recommend: if you think this idea might have merit and would like to read the relevant literature, check out Deming's The Growing Importance of Social Skills in the Labor Market [0]. Here's the abstract:
> The labor market increasingly rewards social skills. Between 1980 and 2012, jobs re- quiring high levels of social interaction grew by nearly 12 percentage points as a share of the U.S. labor force. Math-intensive but less social jobs - including many STEM occu- pations - shrank by 3.3 percentage points over the same period. Employment and wage growth was particularly strong for jobs requiring high levels of both math skill and so- cial skill. To understand these patterns, I develop a model of team production where workers “trade tasks” to exploit their comparative advantage. In the model, social skills reduce coordination costs, allowing workers to specialize and work together more effi- ciently. The model generates predictions about sorting and the relative returns to skill across occupations, which I investigate using data from the NLSY79 and the NLSY97. Using a comparable set of skill measures and covariates across survey waves, I find that the labor market return to social skills was much greater in the 2000s than in the mid 1980s and 1990s.
This post tries to abstract programming away into the OSS community, stackoverflow community, hardware providers etc, and takes the position that programming today requires you to use and direct those resources. Programmers create open source, write helpful SO posts and design hardware and OS.
This reminds me of the assumption that the 'cloud' is making IT personel obsolete, when it's just someone else's computer and IT staff.
> 'cloud' is making IT personel obsolete, when it's just someone else's computer and IT staff.
Worse, it's just someone else's computer and mostly just hardware-IT staff, and that's not the difficult or expensive part, despite the current mythology among those who have never done it.
I'm sure a lot of code gets added to GitHub every day, but the amount that's necessary (not a reimplementation of something that already exists) and not just glue code wiring other components together is probably pretty small.
I'll take it a step further, the author is an idiot. I am a huge proponent of using existing libraries and plugins but it actually takes real code to make it function. Again this person is an idiot and clearly shouldn't be writing code or articles.
He is pointing to a phenomenon I have witnessed which is
copy-pasta and a mediocre understanding of the domain is enough to pass as a programmer these days.
Yikes, harsh. I mostly agree though. I thought this article was silly and couldn't even finish it. I'm not really sure what his point was. Since the conception of software engineering as a discipline, maintainability and code reuse has been highly desirable. It's just taken a while for it to sink in for some people. Re-using code simply means you write different code instead of wasting your time; but you're still writing code.
How much of that (Github) code is based on du jour languages and only a casual attempt (if any) to reuse or adapt an existing codebase? I'd say at least 40% but I may be pessimistic.
> "Programmers do not need to write much code anymore; all they need to do in most cases is wire together already available components."
there are a lot of programmers which develop purely in visual environments such as LabVIEW, Max/MSP, PureData, vvvv, and others - you just don't hear them complaining on hn :p
I would argue that it's also theoretically misguided. After all, it's not like programmers in the past didn't use libraries and pre-built components.
If anything, I'd argue the LOC it takes to accomplish many tasks is actually increasing because applications are held to higher standards of quality, scalability, availability, scope, etc.
You're ignoring the operative word, which is need. You can't say much about that point without actually doing some analysis. For instance, how much of that code is wiring? How much of that code is rewriting existing solutions for educational purposes? And so on.
Easy enough to figure out. Count dependencies in given selection of software, compare to older software in the same area.
I'm certain someone did such surveys.
Software isn't entirely driven by need, sometimes politics or licensing preclude the use of libraries. Sometimes libraries are not specific for your area and cannot be used - typical when handling hard real time applications or when otherwise microseconds matter.
Sure, it's easy enough. But until you can actually point to the surveys, we can't say anything about the code on Github relating to the point being made.
You may be remembering proprietary (e.g. Sun) versus commodity (the prices for which were even lower, according to the table in the sibling comment).
This sort of markup still exists in "enterprise" hardware today, which is why moving to the cloud actually is a cost savings for some places. Of course, operating their own operating their own commodity hardware instead would save even more, but this is typically a political impossibility.
Thinking back it was probably due to currency swings for NZD <-> USD. There was a period of few years back then when the exchange rate could be anywhere between $0.40 USD and $0.75 USD. So $1000 USD could mean very different amounts in NZD depending on exactly when my hazy memories were thinking about.
There were also various Taiwanese earthquakes and resin factory fires etc that probably caused me to remember the price spikes better than the average prices. Well that's my excuse :)
> Edsger W. Dijkstra's words [..] grow increasingly more valuable every year.
Using a Dijkstra quote in an article where sentences such as "The profession now requires less mathematics and algorithms and instead emphasizes more skills under the umbrella term `sociotech.' are used.
I wonder what Prof. Dijkstra would have to say about this "sociotech" umbrella. Actually I don't, because that's the value of having an understanding of a subject matter deeper than an Internet search and a copy and paste: it prevents one from throwing quotes and invented words around that sound good, but ultimately mean nothing useful.
> It seems that the future of programming rests less in math and more in sociotech relationships between people.
Or: it seems that the future of making your fortune with software rests less in math and more in marketing.
True though it may be, I don't know how this relates to the discipline of computer programming.
The article also quotes a misinterpetation of a misstatement of Moore's Law:
> "Computers [have] doubled in power every 18 months for the last 40 years."
This, along with the salary estimate you mentioned made all the numbers in the article quite suspect.
That doesn't necessarily invalidate whatever point the author was trying to make, but it does cast a shadow of lack of seriousness on the whole article.
Long shot, as this is a CACM article. Does anyone in Oxford UK want a 2ft foot worth of paper CACM editions from 2012 to 2015 in Oxford UK? I have been avoiding throwing them out but now getting round to it. Let me know.
If nobody takes them, there’s gotta be a small library somewhere that would accept them, or even one of those Little Free Libraries (if you have them there).
We have a local library run by the council, but I'm not sure if they'd take donations like this. Can't hurt to ask, I suppose.
Then there's the countless libraries in the University of Oxford, some of which might want to stock it, but I'd be surprised if they didn't either already.
Author, Yegor Bugayenko, is misogynist in worst of it. I listened to him being guest on a podcast, where he told that women brain is unfit to perform logical tasks, like coding or planning, and that women are much more fit at home kitchen than in any office.
And I wish I was exaggerating, but one of the hosts was female programmer and he tried to convince her that she's inferior as professional because of her gender.
Egor answers to a question, why his company has only 2 female coders from 500. His answers is a joke "Female Coders are like guinea pigs, neither Hyena neither Pigs. So lets not try to make programmers from women, because they they'are not women and not coders"
Any article from him is about self promotion.
He is trying to promote his views among which are extremely sexist and disgusting ones. He also promotes his startup and anyone backing it should know whom they're dealing with.
To be clear. This is not relevant to the topic.
Just in case you would like to invite Egor to speak at some conference based on this article, I want you to know what opinions you'll get in the "package".
>In order to win in this war, programmers had to be both trained and talented in computer science...
Being long enough in the tooth to have been 'hacking' back then, I'd strongly disagree with that since - and rather obviously given the era - there was little training to be had.
Rather, I'd characterise it as being a time where anyone (irrespective of talent or training) could get their own computer and be the master of it.
Personally, I resent the system trying to take that control away from us (in this case, trying to pass us from an age of controlling our own computers to having to be licensed, controlled and directed in what we can do with them).
I think there are different kinds of programming jobs, and this article is referring to the kind of dev job that puts together pieces to solve problems, but it doesn't work at the fundamental level. to build a new operating system using the capabilities of some new hardware aspect, or say writing a new database that uses nvram and vector instructions to go fast, instead of the older dbs that generated a query and interpreted it row by row. You can't always get there by putting packages together.
There are still people creating fundamental new infrastructure or building blocks. But probably a lot more people are just gluing things together to solve a problem.
97 comments
[ 2.9 ms ] story [ 132 ms ] thread"Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better."
-- Edsger W. Dijkstra
-– C.A.R. Hoare
I know he's a trillionaire and all and probably smarter than me but still - as somebody who spent a full three years reading and working through the problems in the first three books, I wonder how deep an understanding he could really have walked away with after just a few months.
You mean like the MIX (and later MMIX) assembly code used extensively throughout the books?
<author> is founder and CEO of software engineering and management platform <blah>.
I think their case for advancement of development technologies or how much social interaction was needed in the 90's is a bit flawed.
Yeah I'm not interested in what they have to say.
Based purely on my personal experiences, leaders who have both boxes ticked are even more unicorn-y than the fabled 10x engineer.
As if this stops you from re-inventing the wheel in attempt to understand more. Understanding things is what distinguishes programmers.
I had exactly the same discussion with one of my friends that wants to become a programmer. His argument was that programming is not fun at all because all we do is use libraries and frameworks. My counter-argument was the paragraph above.
Most days I feel more like a combination of a preschool teacher and a switchboard operator than a computer scientist.
I'm not really sure how your first paragraph is a counter-argument to your friend. Reinventing the wheel to learn is just busywork. Reinventing the wheel because you need the wheel and don't have one available is fun.
Unfortunately the wheel is always available now.
Edit: Also, I disagree that re-inventing the wheel is just busywork. Compare a programmer that just uses .sort() and another one that uses .sort() and implemented his own sort (disregarding the fact that he is not using his own sort) and really understands the math behind it. Which one would you rely on?
For example, if you are trying to write "business logic", you don't want to have to worry about allocating memory or ensuring data consistency. You just want to worry about business concerns.
I suspect your friend has simply not tried any sufficiently difficult programming project. If your problem is non-trivial, you feel appropriately grateful for libraries that provide higher layers of abstraction.
He implies that this somehow falls into “socitech” ability, which it is not. Maintainable code is precise, well-factored code — almost pedantic — which requires an orthogonal (if not counterpointed) talent to the more “social” talents. I would go further to say that a mathematical understanding or at least inclination is required to write maintainable code. (In the sense that the same is required to write a readable academic paper.)
Another assumption he seems to make here is that somehow there are all these algorithmic hackers who sit and write algorithms all day. No, I doubt this has been some kind of norm ever. Most of what we (business software) programmers write is business logic and data processing with an occasional, infrequent need — but need nevertheless — to break out a unique algorithm.
You can scale up all you want and into the future but we are always going to need to understand the difference between a O(n^2) and O(n) algorithm.
I’m sick of these kinds of pieces that are pure philistinism. The future isn’t going to save you from your lack of technical skills, education and awareness. Stay curious and develop yourself — your social self as much as your craft and profession.
Maintainable code is more an act of writing than of mathematics.
Since it's similar to math, it's as clear as it can be. Like functional programming - the cleanest code is one line of code which expresses the intent as an mathematical function.
1. To reduce the number of changes that will need to be made to it.
2. To reduce the time it takes to make each change.
The (1) category encompasses the idea of making code that requires few changes. Such code is essentially "right" to begin with. I think about this mostly in terms of models -- i.e. does it accurately model the problem -- and quality -- i.e. does it have bugs or performance issues. Of course there are other concerns as well, but those are two big ones and they often involve thinking like a "computer scientist."
The (2) category -- reducing the effort of changes -- is achieved by using appropriate abstraction layers, encapsulation, low coupling, and other good-program design. There are many technical concerns in this category, but it seems there are some social ones as well.
I would say the programmer's experience is another huge factor. To sum it up in a phrase, perhaps "writing maintainable code is an act of prediction."
Wouldn't programmers know how to code it themselves without req. Stack Overflow? I would be pissed spending $100k /year on programmer who uses Stack Overflow.
Stack overflow is a valuable resource. I'd be pissed if my boss told me not to use it.
"How often they need to refer to reference material" is a pretty terrible metric for measuring the abilities of a programmer.
Its similar to being unable to do math in your head. You can get away with always using the calculator but you'll be outperformed by someone who can do it without dropping their pencil.
They're not wrong about the first part. Tiling window managers are very efficient. They are wrong about that making them more productive, though. It certainly makes them feel more productive, but this kind of micro-optimization is solving something that wasn't actually a huge productivity problem to begin with. You can add up all the time I spend switching windows in a slightly suboptimal manner on Gnome or Windows and all of that time will be lost by an extra 5 minute coffee break or the mental deficit from sleeping less than 8ish hours a night.
Similarly, a person who doesn't have to look at Stack Overflow may seem more productive, but the tiny amount of time it takes to look something up instead of remembering it is a very, very small part of the developers day. Even if they have to do it 100 times a day it's unlikely to make any meaningful difference in the big picture.
Not needing documentation would be helpful in a world where a programmer sat down and didn't stop typing for 8 hours, but that's not the world that we live in.
100*1 minute is an hour and 40 minutes. That is not a trivial portion of the work day. Even if it were 30 seconds that's still almost an hour.
If that is truly a micro optimization then I shudder to think of the waste elsewhere.
Suppose candidate A tends to communicate in terms of specs and reference implementations. Candidate B tends to communicate in terms of accepted answers and discussions on Stack Overflow.
All other things being equal that should be an easy choice.
I have also seen entire teams that would not really notice if the internet was working.
Stack Overflow has a place in productive development, but I agree - people should be able to function without it.
1) Posting general questions about "coding", like syntax questions, ie- "how do you create a loop in JavaScript"
2) Posting specific, targeted questions about specifics of something the dev doesn't do on a regular basis, ie- "how do you use Google OAuth for logins"
3) Searching existing SO posts for general questions about "coding", ie- Google search for "what is the difference between let and var in JavaScript", read first SO result
4) Searching existing SO posts for the specifics, ie- Google search for "how to manage cross-tab communication using javascript", read first SO result
I would argue that a competent dev would (and should!) utilize SO using the 4th strategy on a regular basis (maybe weekly for a web dev) and occasionally the 2nd when all other resources have been exhausted. If you are paying someone $100k, yeah I agree that the first usage pattern is inappropriate, but saying "a developer shouldn't need to use StackOverflow" is a gross oversimplification of the vast knowledge that exists in SO.
The average salary for a Programmer is $89,128 in San Francisco, CA. Salaries estimates are based on 238 salaries submitted anonymously to Glassdoor by Programmer employees in San Francisco, CA....
are coders really making $240k /year?
https://www.glassdoor.ca/Salaries/san-francisco-programmer-s...?
Confused by the downvotes. Programmer: $89k. Software Engineer: $137k.
This guy also seems to think programmers are so mentally deficient they are unable communicate with the 'open source community' and that this is in some way how programmers discover new technologies. He also thinks people did not contribute code in the 1990s. Where did all this software come from? Typical business view of open source. Originally b-schools actually lectured that open source was anti-business like a trade union. Now I guess they think it is sort of a crutch for too-dumb-to-breathe programmers?
There are tons of people like this guy in tech. Coded a year or two and found out the were a taker and not a maker. Still pretending to be a maker though. Their idealized programmer befits a corporation. Colors in the lines and writes "perfect code" which has no meaning other than has been annointed by CR's as to make it seem owned by the company rather than the individual. Their ideal programmer is someone who doesn't need to understand the details, works as a unit in a team, and gathers all of their knowledge by "getting help" from the company. It is absolutely blasphemy in the corporate world to suggest that anyone synthesize his or her own ideas. That's of course ridiculous but in a business setting, the takers absolutely must discount creative thought of employees 100% which literally the "product" up for grabs in tech companies. Obviously if people knew the value and how to exploit their own original ideas they wouldn't need the fucking company or takers.
As far as math and algorithms, those are more important than ever. The reason you don't see people working on those is that those people are hidden from public and private view, jealously guarded by the takers who think they control them. Natural sciences did not fucking change since the 90's. A surface to air missile or high frequency trading algorithm or advanced simulation is as costly and valuable as ever. It's the author perception of what is valuable that has changed. He's looking for code monkeys to exploit who will "get help" and write "clean code" whatever the hell that means.
"Website obesity" [0] is a phenomenon where this is especially evident.
[0] http://idlewords.com/talks/website_obesity.htm
> The labor market increasingly rewards social skills. Between 1980 and 2012, jobs re- quiring high levels of social interaction grew by nearly 12 percentage points as a share of the U.S. labor force. Math-intensive but less social jobs - including many STEM occu- pations - shrank by 3.3 percentage points over the same period. Employment and wage growth was particularly strong for jobs requiring high levels of both math skill and so- cial skill. To understand these patterns, I develop a model of team production where workers “trade tasks” to exploit their comparative advantage. In the model, social skills reduce coordination costs, allowing workers to specialize and work together more effi- ciently. The model generates predictions about sorting and the relative returns to skill across occupations, which I investigate using data from the NLSY79 and the NLSY97. Using a comparable set of skill measures and covariates across survey waves, I find that the labor market return to social skills was much greater in the 2000s than in the mid 1980s and 1990s.
[0]: https://scholar.harvard.edu/files/ddeming/files/deming_socia...
[0]. https://strikemag.org/bullshit-jobs/
This reminds me of the assumption that the 'cloud' is making IT personel obsolete, when it's just someone else's computer and IT staff.
Worse, it's just someone else's computer and mostly just hardware-IT staff, and that's not the difficult or expensive part, despite the current mythology among those who have never done it.
As a general statement, I feel like this is objectively false. Just look at how much code gets added to Github daily.
https://news.ycombinator.com/newsguidelines.html
there are a lot of programmers which develop purely in visual environments such as LabVIEW, Max/MSP, PureData, vvvv, and others - you just don't hear them complaining on hn :p
If anything, I'd argue the LOC it takes to accomplish many tasks is actually increasing because applications are held to higher standards of quality, scalability, availability, scope, etc.
I'm certain someone did such surveys.
Software isn't entirely driven by need, sometimes politics or licensing preclude the use of libraries. Sometimes libraries are not specific for your area and cannot be used - typical when handling hard real time applications or when otherwise microseconds matter.
Sure, it's easy enough. But until you can actually point to the surveys, we can't say anything about the code on Github relating to the point being made.
If you had enough memory slots on the motherboard.
This sort of markup still exists in "enterprise" hardware today, which is why moving to the cloud actually is a cost savings for some places. Of course, operating their own operating their own commodity hardware instead would save even more, but this is typically a political impossibility.
There were also various Taiwanese earthquakes and resin factory fires etc that probably caused me to remember the price spikes better than the average prices. Well that's my excuse :)
Using a Dijkstra quote in an article where sentences such as "The profession now requires less mathematics and algorithms and instead emphasizes more skills under the umbrella term `sociotech.' are used.
I wonder what Prof. Dijkstra would have to say about this "sociotech" umbrella. Actually I don't, because that's the value of having an understanding of a subject matter deeper than an Internet search and a copy and paste: it prevents one from throwing quotes and invented words around that sound good, but ultimately mean nothing useful.
> It seems that the future of programming rests less in math and more in sociotech relationships between people.
Or: it seems that the future of making your fortune with software rests less in math and more in marketing.
True though it may be, I don't know how this relates to the discipline of computer programming.
That's news to me.
> "Computers [have] doubled in power every 18 months for the last 40 years."
This, along with the salary estimate you mentioned made all the numbers in the article quite suspect.
That doesn't necessarily invalidate whatever point the author was trying to make, but it does cast a shadow of lack of seriousness on the whole article.
Then there's the countless libraries in the University of Oxford, some of which might want to stock it, but I'd be surprised if they didn't either already.
Egor answers to a question, why his company has only 2 female coders from 500. His answers is a joke "Female Coders are like guinea pigs, neither Hyena neither Pigs. So lets not try to make programmers from women, because they they'are not women and not coders"
Being long enough in the tooth to have been 'hacking' back then, I'd strongly disagree with that since - and rather obviously given the era - there was little training to be had.
Rather, I'd characterise it as being a time where anyone (irrespective of talent or training) could get their own computer and be the master of it.
Personally, I resent the system trying to take that control away from us (in this case, trying to pass us from an age of controlling our own computers to having to be licensed, controlled and directed in what we can do with them).
There are still people creating fundamental new infrastructure or building blocks. But probably a lot more people are just gluing things together to solve a problem.