Why programming is difficult (2014)(joearms.github.io)
joearms.github.io
Why programming is difficult (2014)
https://joearms.github.io/#2014-02-07%20Why%20programming%20is%20difficult
90 comments
I've spent most of my adult life as as "full stack" developer, out of necessity: I build the whole banana on my own and typically work on projects on my own (about 3/4 of the last 20 years). I'm better at some aspects than others and I enjoy some aspects more than others, of course (and I offload/automate anywhere I can).
From the late 1990s until five or six years ago, it was fairly easy to keep up with the latest interesting stuff in terms of full stack. Adjustments were modest year to year. At this point I've entirely given up trying to keep up with the very rapid fad switching that has been going on. Real full stack is now only possible if you freeze pretty strictly across the stack and don't try to keep up as the next fad rolls in for a given part of the stack. If you try to keep up with all the fads now, it'll burn you out (and most likely make you hate what you do as you realize how pointless the constant switching is).
I've found - as you'd expect - that abandoning the stack rat race hasn't had any negative impact. Most of the latest fads are entirely unnecessary and bring nothing to the table that prior numerous solutions didn't already deliver toward building, launching and maintaining product.
From the late 1990s until five or six years ago, it was fairly easy to keep up with the latest interesting stuff in terms of full stack. Adjustments were modest year to year. At this point I've entirely given up trying to keep up with the very rapid fad switching that has been going on. Real full stack is now only possible if you freeze pretty strictly across the stack and don't try to keep up as the next fad rolls in for a given part of the stack. If you try to keep up with all the fads now, it'll burn you out (and most likely make you hate what you do as you realize how pointless the constant switching is).
I've found - as you'd expect - that abandoning the stack rat race hasn't had any negative impact. Most of the latest fads are entirely unnecessary and bring nothing to the table that prior numerous solutions didn't already deliver toward building, launching and maintaining product.
This is the other side of the coin. A lot of folks in the industry, especially on the younger side, tend to believe they are operating at FAANG levels of data and complexities. What happens is that you get convoluted, over-engineered architectures and applications which really do nothing other than pad resumes. The next time you are listening to a talk or reading a blog entry that drones on about how complex their stack is, stop and think for a moment: "Do they really have traffic/MAU levels that merit this approach? Are they really operating on data that is PB scale or just a few GBs?" More often than not, the answer is an emphatic No ... or "Can this application be distilled down to a vanilla MVC app with a few cronjobs running?" Yes.
>What happens is that you get convoluted, over-engineered architectures and applications which really do nothing other than pad resumes.
But padding resumes is one of those seemingly fundamental problems of any industry (or bureaucracy). Many poor decisions by (middle) management come down to padding resumes - when the consequences of bad decisions eventually happen said managers are gone. Hell, you could even argue that a lot of higher education is about padding your resume rather than learning skills. Unfortunately, it seems that we have to live with the added baggage of "padding resumes".
But padding resumes is one of those seemingly fundamental problems of any industry (or bureaucracy). Many poor decisions by (middle) management come down to padding resumes - when the consequences of bad decisions eventually happen said managers are gone. Hell, you could even argue that a lot of higher education is about padding your resume rather than learning skills. Unfortunately, it seems that we have to live with the added baggage of "padding resumes".
Maybe the point _is_ to pad resumes, ie Resume Driven Development. The incentives align for this to take place, as companies want to hire for the trendiest and newest technologies, simply as a way of virtue signaling that they're good, regardless of the efficacy of the new technologies. If I can job hop every few years while padding my resume, and get paid 30% more each time, for some N job hops, why wouldn't I? In this case, when you follow the incentives, you see why this happens. That the incentives of the business don't align exactly (stability, speed, efficiency to some regard) is inconsequential to the developer who wants to increase their value.
I will argue that some projects are definitely overly architectured simply for the sake of gaining experience in doing so. If everyone waited until they actually had Google scale problems to learn how to create scalable architecture, then only a small subset of people would have that skill. It is the initiative of doing so and ability to point at previous history of successfully completing such projects that give these people the opportunity to work on problems that actually require said complex solutions.
I think the reason programming is difficult is that really we are dealing with incomplete information while the device that runs your program does not care you have incomplete information and wants to screw you the first time you do something not right in the slightest.
Programming is not just understanding how the device, language, libraries work (ie. getting more complete information) but also limiting the ways the adversary can screw you and limiting the fallout.
Programming is difficult because developers don't appreciate how important the part of managing this incomplete information is. "I wrote this and it works! Yeay!" And then it goes in prod and fails instantly because you did not take this or that into account.
Some bright developers have the ability to manage this. But the problem is that they can't work really well with other developers (at a typical corp) who don't appreciate the problem the same way. This puts them in this untenable positions where they can either do something by themselves, very efficiently, or rely on extremely inefficient process if they want to work with other developers.
Programming is not just understanding how the device, language, libraries work (ie. getting more complete information) but also limiting the ways the adversary can screw you and limiting the fallout.
Programming is difficult because developers don't appreciate how important the part of managing this incomplete information is. "I wrote this and it works! Yeay!" And then it goes in prod and fails instantly because you did not take this or that into account.
Some bright developers have the ability to manage this. But the problem is that they can't work really well with other developers (at a typical corp) who don't appreciate the problem the same way. This puts them in this untenable positions where they can either do something by themselves, very efficiently, or rely on extremely inefficient process if they want to work with other developers.
> "...we are dealing with incomplete information while the device that runs your program does not care you have incomplete information and wants to screw you the first time you do something not right in the slightest."
Suppose you're becoming pretty comfortable with your skills in a foreign language and you've become pretty decent at speaking it. Occasionally you'll make a mistake---you'll pronounce a word incorrectly, misplace a verb, etc---and chances are the person you're speaking with will be able to figure out what you meant to say.
Unfortunately, computers don't work that way. If you're writing a function and your syntax is incorrect, the browser won't understand what you're trying to do.
Suppose you're becoming pretty comfortable with your skills in a foreign language and you've become pretty decent at speaking it. Occasionally you'll make a mistake---you'll pronounce a word incorrectly, misplace a verb, etc---and chances are the person you're speaking with will be able to figure out what you meant to say.
Unfortunately, computers don't work that way. If you're writing a function and your syntax is incorrect, the browser won't understand what you're trying to do.
>Unfortunately, computers don't work that way. If you're writing a function and your syntax is incorrect, the browser won't understand what you're trying to do.
Or worse, you and the computer have different understandings about what you're trying to do and it goes along quietly incorrectly for a while until that little mistake causes a problem somewhere else entirely because that one misunderstanding caused a cascade of misunderstandings that kept building up until it finally blew out everywhere all over your program and the quest to find where the problem started begins, well before the task of fixing the problem can start.
Or worse, you and the computer have different understandings about what you're trying to do and it goes along quietly incorrectly for a while until that little mistake causes a problem somewhere else entirely because that one misunderstanding caused a cascade of misunderstandings that kept building up until it finally blew out everywhere all over your program and the quest to find where the problem started begins, well before the task of fixing the problem can start.
> But the problem is that they can't work really well with other developers (at a typical corp) who don't appreciate the problem the same way.
The key is to not work at a typical corp! :)
The key is to not work at a typical corp! :)
“I think the reason programming is difficult is that really we are dealing with incomplete information”
Dealing with uncertainty and incompleteness is a core part of the job.
The problem is that far too many programmers are gloryhounds and cowboys who think all that is beneath them; cramping their style when they’re trying to be the coding heroes.
This is compounded by many programmers being lazy incurious bums who have zero interest in doing anything that isn’t writing code. They don’t want to learn the user’s problem domain, so they don’t. Instead they demand users describe exactly how the software should work down to the very last detail; but if users could do that for themselves then they wouldn’t need programmers to write it for them!
Starting from ignorance, instead of writing software that encapsulates the users’ expert requirements, they write clever code that solves their own problems: entertaining themselves, and getting paid.
Writing code is not hard. Any monkey can do that. The challenge is knowing what code to write; and that’s made needlessly hard by programmers who can’t be arsed to understand their users, what they do and why they do it, learning their needs and problems in order to synthesize more effective solutions.
Instead of raising themselves up to users’ level of knowledge, they drag the problem down to their level of ignorance and whale on it with their crappy tools to give the illusion of “productivity”. Instead of being problem solvers, they’re problem multipliers.
Slap on several more layers of equally useless management, marketeers, beancounters, etc, and factor in that while deadweight accummulates expertise walks, and it’s no surprise most software projects are rolling Katamari disasters that makes everyone miserable until finally put out their misery; only for the whole process to start over again, with zero lessons learned.
--
TL;DR: Programming is hard because programmers make it hard. Because they don’t want to do the job right. Because they’re children.
Dealing with uncertainty and incompleteness is a core part of the job.
The problem is that far too many programmers are gloryhounds and cowboys who think all that is beneath them; cramping their style when they’re trying to be the coding heroes.
This is compounded by many programmers being lazy incurious bums who have zero interest in doing anything that isn’t writing code. They don’t want to learn the user’s problem domain, so they don’t. Instead they demand users describe exactly how the software should work down to the very last detail; but if users could do that for themselves then they wouldn’t need programmers to write it for them!
Starting from ignorance, instead of writing software that encapsulates the users’ expert requirements, they write clever code that solves their own problems: entertaining themselves, and getting paid.
Writing code is not hard. Any monkey can do that. The challenge is knowing what code to write; and that’s made needlessly hard by programmers who can’t be arsed to understand their users, what they do and why they do it, learning their needs and problems in order to synthesize more effective solutions.
Instead of raising themselves up to users’ level of knowledge, they drag the problem down to their level of ignorance and whale on it with their crappy tools to give the illusion of “productivity”. Instead of being problem solvers, they’re problem multipliers.
Slap on several more layers of equally useless management, marketeers, beancounters, etc, and factor in that while deadweight accummulates expertise walks, and it’s no surprise most software projects are rolling Katamari disasters that makes everyone miserable until finally put out their misery; only for the whole process to start over again, with zero lessons learned.
--
TL;DR: Programming is hard because programmers make it hard. Because they don’t want to do the job right. Because they’re children.
> Programming is hard because programmers make it hard
This has been the MBA's wish/dream/hope for about a half-century now: “if only programming were easy and programmers didn’t take so long,” they think, “I could be making millions off of this business.” Since they want this to be true, they reason, it must be true. They then insist, in spite of mountains of evidence to the contrary, that programming is easy, and the entire industry of programmers - every single one, including the ones who were educated recently, including the ones from foreign countries - are conspiring against them to make it seem like it’s harder than it really is.
This has been the MBA's wish/dream/hope for about a half-century now: “if only programming were easy and programmers didn’t take so long,” they think, “I could be making millions off of this business.” Since they want this to be true, they reason, it must be true. They then insist, in spite of mountains of evidence to the contrary, that programming is easy, and the entire industry of programmers - every single one, including the ones who were educated recently, including the ones from foreign countries - are conspiring against them to make it seem like it’s harder than it really is.
Also, MBAs assume then can hire anyone and then they complain the performance suffers.
The truth is, development is a high skill profession. It should take decades to master if we were really realistic about it.
The truth is, development is a high skill profession. It should take decades to master if we were really realistic about it.
So many generalizations in this paragraph.
Not all programmers try to be heroes and cowboys throughout their whole careers. I am myself a programmer (25+ years doing it), and have known programmers my entire life. The distribution of certain personality traits is not better or worse in any given population.
Besides our 'lazy' and 'childish' ways, we also have to contend with business constraints and everything needs to be shipped for yesterday.
So although I do agree programmers should be more aware of the domain knowledge and be more 'client' oriented, it's also true that business stakeholders need to take the time and understand the impacts of their 'ship fast always' mentality. Too many times there is no counterweight to business decisions that lead to overwhelming technical debt, which is a great deservice to customers in long term business sense.
It's never black or white.
Not all programmers try to be heroes and cowboys throughout their whole careers. I am myself a programmer (25+ years doing it), and have known programmers my entire life. The distribution of certain personality traits is not better or worse in any given population.
Besides our 'lazy' and 'childish' ways, we also have to contend with business constraints and everything needs to be shipped for yesterday.
So although I do agree programmers should be more aware of the domain knowledge and be more 'client' oriented, it's also true that business stakeholders need to take the time and understand the impacts of their 'ship fast always' mentality. Too many times there is no counterweight to business decisions that lead to overwhelming technical debt, which is a great deservice to customers in long term business sense.
It's never black or white.
Where did I say “all”?
I said “far too many”. Although judging by the amount of crap software around, it’s certainly a lot.
“it's also true that business stakeholders need to take the time and understand the impacts of their 'ship fast always' mentality”
You’ll note where my original post points out programmers are not the only culprits at work. Learning is a two-way process. But developers are ostensibly the experts in turning requirements into solutions and what is needed to do that; so if users have utterly unrealistic expectations of what is/isn’t achievable then whose fault is that?
Often what users want is feedback: they want to know when they’ll be getting their solution, and be confident it does what they need. Both of these are engagement problems. That points to logistical shortcomings in the development cycle, particularly the siloing of parties and processes, which I know is a blight in which everyone is at fault.
But a lot of programmers would far rather wrangle code than wrangle users, even though user-wrangling is by far the more important of the two. So what does that say about these “solutions providers” and their ability to deliver?
Me, I’ve only been coding 20 years; professionally the last 10. My first programming job, I was one of two devs attached to the IT team out on the shop floor, working directly with users developing them quick-turnaround solutions to their immediate problems. In the 3 years I was there, I never once saw a developer from their 20+ Enterprise Applications department walk out of their glass cage onto the shop floor and spend some time talking to users about how they were getting on with their software and any problems they might be having.
Sure our code was small and simple, and theirs large and complex. But that’s all the more reason for them to engage closely and constantly with users, in order to avoid large and costly errors downstream that embarrass and frustrate everyone.
As I say, the problem is not in the code but in the people and their processes. Yet, no prizes for guessing where most programmers will try to solve it.
I said “far too many”. Although judging by the amount of crap software around, it’s certainly a lot.
“it's also true that business stakeholders need to take the time and understand the impacts of their 'ship fast always' mentality”
You’ll note where my original post points out programmers are not the only culprits at work. Learning is a two-way process. But developers are ostensibly the experts in turning requirements into solutions and what is needed to do that; so if users have utterly unrealistic expectations of what is/isn’t achievable then whose fault is that?
Often what users want is feedback: they want to know when they’ll be getting their solution, and be confident it does what they need. Both of these are engagement problems. That points to logistical shortcomings in the development cycle, particularly the siloing of parties and processes, which I know is a blight in which everyone is at fault.
But a lot of programmers would far rather wrangle code than wrangle users, even though user-wrangling is by far the more important of the two. So what does that say about these “solutions providers” and their ability to deliver?
Me, I’ve only been coding 20 years; professionally the last 10. My first programming job, I was one of two devs attached to the IT team out on the shop floor, working directly with users developing them quick-turnaround solutions to their immediate problems. In the 3 years I was there, I never once saw a developer from their 20+ Enterprise Applications department walk out of their glass cage onto the shop floor and spend some time talking to users about how they were getting on with their software and any problems they might be having.
Sure our code was small and simple, and theirs large and complex. But that’s all the more reason for them to engage closely and constantly with users, in order to avoid large and costly errors downstream that embarrass and frustrate everyone.
As I say, the problem is not in the code but in the people and their processes. Yet, no prizes for guessing where most programmers will try to solve it.
I think there lies the misunderstanding:
"Sure our code was small and simple, and theirs large and complex"
Having a complex piece of code, maybe with a lot of 'historical cruft' and legacy 3rd party modules? Business politics? Maybe a new manager wants his programming team to work on 'Shiny X' because that will make him/her look better with upper management?
Trust me, 95% of programmers (and most people for that matter) would rather feel like they are doing a valuable service and adding value to a product or service, than simply and lazily going through the motions of 'coding'.
Until you've walked a mile in some 'Enterprise application developer', or any one else I think it will be difficult for you to evaluate the global picture.
Although I understand you frustration and completely agree with the symptoms you mention, the cause is far more complex and difficult to grasp unfortunately.
"Sure our code was small and simple, and theirs large and complex"
Having a complex piece of code, maybe with a lot of 'historical cruft' and legacy 3rd party modules? Business politics? Maybe a new manager wants his programming team to work on 'Shiny X' because that will make him/her look better with upper management?
Trust me, 95% of programmers (and most people for that matter) would rather feel like they are doing a valuable service and adding value to a product or service, than simply and lazily going through the motions of 'coding'.
Until you've walked a mile in some 'Enterprise application developer', or any one else I think it will be difficult for you to evaluate the global picture.
Although I understand you frustration and completely agree with the symptoms you mention, the cause is far more complex and difficult to grasp unfortunately.
If you're right (and I'm not sure that you are) then this seems to be a systemic, or at least cultural, problem. It's certainly not inherent to software; you're talking about individuals' attitudes. So how do we change that and inculcate values like being user-aware in people coming into the field? How do we get the other components of the business to support this?[0]
[0]:At my current job I'm completely insulated from users and I would really prefer not to be, but that's "the way it is".
[0]:At my current job I'm completely insulated from users and I would really prefer not to be, but that's "the way it is".
Well, users who have perfect knowledge of their domain, of what they do and why, can't get arsed to learn to code and do it themselves when any monkey can do that.
It is almost like people have different domains of expertise because getting those skills takes time an effort, and specialists will always run circles around generalists in any non-trivial domain.
It is almost like people have different domains of expertise because getting those skills takes time an effort, and specialists will always run circles around generalists in any non-trivial domain.
[deleted]
There is a reason why people make a distinction between "Programming" and "Software Engineering". Programming is just the act of writing code. All you have to do is learn a programming language and you are set.
"Software Engineering" encompasses everything else on top of programming. You need knowledge of these things: build systems (Make/Gradle), filesystems, networking (IP/TCP/HTTP), Data formats (JSON/XML), Databases(SQL/KV), software architecture, layout/styling, documentation (both reading and writing). This list is just scratching the surface but we can agree that all of these things are critical to build applications.
These topics clearly aren't exclusive to "Programming" and knowing them doesn't mean you are a "Programmer". You could also be a sysadmin that is managing a large cluster for multiple applications. But if you are a Software Engineer and not just a mere "Programmer" you know that your job is much much more difficult than merely the "Programmer" part.
"Software Engineering" encompasses everything else on top of programming. You need knowledge of these things: build systems (Make/Gradle), filesystems, networking (IP/TCP/HTTP), Data formats (JSON/XML), Databases(SQL/KV), software architecture, layout/styling, documentation (both reading and writing). This list is just scratching the surface but we can agree that all of these things are critical to build applications.
These topics clearly aren't exclusive to "Programming" and knowing them doesn't mean you are a "Programmer". You could also be a sysadmin that is managing a large cluster for multiple applications. But if you are a Software Engineer and not just a mere "Programmer" you know that your job is much much more difficult than merely the "Programmer" part.
Is software engineering a real engineering discipline, though? I have a hard time saying yes when "software engineers" make mistakes that are well documented, no certification is necessary, and it isn't a legal definition.
Man, the people who push certification systems on the software engineering community really burn my biscuits.
I haven't seen a certification system that wasn't either a money-grab (product-specific certifications, like Windows or Novell), a power-grab (by someone like the IEEE, where the tests were half electrical engineering and the software bits were garbage practices from the 70s and 80s), or a way to artificially restrict the number of available practitioners (arguably another money-grab).
No certification system is going to magically make large systems easier to write or whisk away bugs. Writing software is hard. It's that simple. People who have spent their entire careers writing software, from industry luminaries that you read about every day to the really, really good engineers you've never heard of, who are absolute wizards, these people are still writing howlingly bad bugs because writing software is hard.
You can have your certifications and legal requirements for training and so on, just don't pretend they will improve the state of the art. The best you can do is hold people's feet to the fire after they make mistakes, and if the best people in the industry can't be perfect, why would we expect threats of punishment to fix anything?
Engineering is about designing and building systems, usually with cost, time and reliability constraints. It's totally separate from whatever liability framework is being enforced this week.
I haven't seen a certification system that wasn't either a money-grab (product-specific certifications, like Windows or Novell), a power-grab (by someone like the IEEE, where the tests were half electrical engineering and the software bits were garbage practices from the 70s and 80s), or a way to artificially restrict the number of available practitioners (arguably another money-grab).
No certification system is going to magically make large systems easier to write or whisk away bugs. Writing software is hard. It's that simple. People who have spent their entire careers writing software, from industry luminaries that you read about every day to the really, really good engineers you've never heard of, who are absolute wizards, these people are still writing howlingly bad bugs because writing software is hard.
You can have your certifications and legal requirements for training and so on, just don't pretend they will improve the state of the art. The best you can do is hold people's feet to the fire after they make mistakes, and if the best people in the industry can't be perfect, why would we expect threats of punishment to fix anything?
Engineering is about designing and building systems, usually with cost, time and reliability constraints. It's totally separate from whatever liability framework is being enforced this week.
It's not about being perfect, it's about being fault tolerant, just like regular engineering. I think especially for safety-critical situations (cough Boeing cough) there needs to be stringent, formal standards for quality, review, and training. It should not be possible to cheap out or ship a pile of duct-taped garbage in some situations, and that requires external review by subject matter experts. (Not necessarily government bodies, especially with the regulatory capture and brain drain going on right now.)
Agreed.
I am a "Software Engineer". I hold a Professional Engineer designation by APEGS, my schooling was for Software Engineering. I advocate for regulation in the industry but also don't think it needs to be sweeping and catch-all.
My job has me working within Industrial Control environments. Programming mistakes can kill people or damage equipment worth millions. When I receive a software package from someone I want to have some trust in a system that this person wasn't hired off the street for lowest wage. My employer has a good reputation in our industry and is asked to come clean up messes from programmers overseas who provide a bad system and walk away from it.
If your job doesn't have you playing with lives of people or holding the wellbeing of a company in your hands then regulation shouldn't be as stringent. But to say that every project of that magnitude has an Engineer overseeing and holding responsibility over it isn't overreaching imo.
I am a "Software Engineer". I hold a Professional Engineer designation by APEGS, my schooling was for Software Engineering. I advocate for regulation in the industry but also don't think it needs to be sweeping and catch-all.
My job has me working within Industrial Control environments. Programming mistakes can kill people or damage equipment worth millions. When I receive a software package from someone I want to have some trust in a system that this person wasn't hired off the street for lowest wage. My employer has a good reputation in our industry and is asked to come clean up messes from programmers overseas who provide a bad system and walk away from it.
If your job doesn't have you playing with lives of people or holding the wellbeing of a company in your hands then regulation shouldn't be as stringent. But to say that every project of that magnitude has an Engineer overseeing and holding responsibility over it isn't overreaching imo.
I think kabdib's point is that the incentives of certification authorities aren't aligned with the purported goal of the certification process. We already have all sorts of certifications (in specific technologies, "agile" practices, etc.) but I don't think most engineers see those certifications as providing any value.
The only thing I'm aware of that seems to actually work is to hold engineers accountable for results and give them the autonomy to set their own process. I would argue that even very rigorous methodologies like NASA's Systems Engineering[0] process match that description.
[0] https://www.nasa.gov/connect/ebooks/nasa-systems-engineering...
The only thing I'm aware of that seems to actually work is to hold engineers accountable for results and give them the autonomy to set their own process. I would argue that even very rigorous methodologies like NASA's Systems Engineering[0] process match that description.
[0] https://www.nasa.gov/connect/ebooks/nasa-systems-engineering...
I think they were advocating something along the lines of a Public Engineer certification, not the trivially useless certifications we have today. One of the things making programming difficult are inexperienced people kibitzing with management and telling them the reason things are taking so long is the experienced people are gold-plating everything. Professional certifications would go a long way toward solving that problem.
OTOH, not every engineering project requires a PE - and the same would be true for programming as well. Unless money, lives or other regulatory items were on the line then a PE would not be required. That would still leave the overwhelming majority of software not requiring any form of certification for its creators. So there's that.
OTOH, not every engineering project requires a PE - and the same would be true for programming as well. Unless money, lives or other regulatory items were on the line then a PE would not be required. That would still leave the overwhelming majority of software not requiring any form of certification for its creators. So there's that.
I think you meant to say Professional Engineer rather than Public Engineer
> Is software engineering a real engineering discipline, though?
Maybe it isn't yet, but I hope that there will come a day in my lifetime that it is.
Maybe it isn't yet, but I hope that there will come a day in my lifetime that it is.
https://en.wikipedia.org/wiki/List_of_data_breaches
With such a list, one would hope software engineering becomes a protected title
With such a list, one would hope software engineering becomes a protected title
But will that really help though? It'll just be another mechanism for signaling, but that doesn't mean it will improve the situation, because the technology moves so fast that it's virtually impossible for the certification to be relevant, unless you mandate that software engineers get a certificate every year in some arbitrary newest technologies.
Engineering is a field where we understand the fundamentals. Changes from year to year or even decade to decade aren't going to uproot half of the things you know about it. In software that can very much be the case.
Engineering is a field where we understand the fundamentals. Changes from year to year or even decade to decade aren't going to uproot half of the things you know about it. In software that can very much be the case.
Goodhart's Law applies, so you can't have a set-and-forget certification process. It can be a dynamic process. And just perhaps, we should disincentivize trying to launch new technologies when the institutional knowledge is not there yet. I wonder how many of those security compromises come from bad tradeoffs trying to "keep up with the Joneses" instead of addressing technical debt and knowledge gaps?
The problem is that this is an industry of tinkerers. A lot of projects started out and continue to be maintained by people that do it as a side project. How are you going to police that? People seem to build software as a hobby and sometimes that morphs into a library.
If a tinkering structural engineer designed some new type of, say, a joist, would builders just throw it into a new structure because it's new, or would it need a vetting and review process before becoming a structural dependency? Review doesn't need to happen at the creative level, just at the level where new code gets integrated in some non-trivial, safety-critical deployment. That happens informally now, as people submit issues, pull requests, etc. for projects that they're interested in, but sometimes that is not enough and calls for something more rigorous, like the peer review process in science. Things like the npm left-pad incident clearly show that we're favoring expediency and speed far too much over resiliency. Software now in many places is where architecture was before building codes and fire escapes.
Depends on how you define "real engineer." In the US, you do not need a certification to call yourself an engineer.
In my state, you need a license to offer engineering services to the public, but not if you work for an industrial employer. However, your design may have to go through a regulatory approval process, and the people who are hired for that work are licensed engineers. In some fields such as civil and nuclear engineering, so much of the work is regulatory, that they only hire licensed engineers as a matter of course.
In my view, "engineer" is getting harder to define. At my workplace, anybody who does anything techy and has a degree is an "engineer" if in the product development department, or a "scientist" if in R&D. Only a small handful of the engineers do what a traditionalist would recognize as "hard" quantitative engineering. Most of the work is fitting building blocks together, troubleshooting, bureaucracy, etc.
In my view, "engineer" is getting harder to define. At my workplace, anybody who does anything techy and has a degree is an "engineer" if in the product development department, or a "scientist" if in R&D. Only a small handful of the engineers do what a traditionalist would recognize as "hard" quantitative engineering. Most of the work is fitting building blocks together, troubleshooting, bureaucracy, etc.
Yes, because you can be a chartered engineer off the back of software development experience and a CS Masters. There isn't a more definitive way to say yes or no than that imo.
Really? I have a CS Masters and people question my abilities all the time.
Must be the tits.
Must be the tits.
This is in the UK but yeah - you can get Chartered status for sure!
Doesn’t mean people won’t question your abilities but it helps with signalling
Doesn’t mean people won’t question your abilities but it helps with signalling
You would also have to dismiss mechanical and electrical engineers then, right? Licensing requirements are only ubiquitous in civil engineering.
I wouldn't even call that a software engineer. That's a dev. A software engineer can promise an sla and understand what factors go into that sla and what constraints, when violated, lead to the sla being out of compliance.
This is analogous to, for example, a civil engineer certifying a bridge for a certain load with a safety factor.
This is analogous to, for example, a civil engineer certifying a bridge for a certain load with a safety factor.
But what to do if you have a CS degree with knowledge of all the things you mentioned and perhaps more, but people keep calling you "programmer"?
As long as I'm paid a software engineering salary to develop software, I could be called a clown for all the difference it makes.
If you're programming, you're a programmer. Or a coder. Or a software developer. Or a software engineer. There is no consensus on the distinction between any of these things. Just lots of people with opinions because it's easy to have an opinion on.
If you're programming, you're a programmer. Or a coder. Or a software developer. Or a software engineer. There is no consensus on the distinction between any of these things. Just lots of people with opinions because it's easy to have an opinion on.
Titles are both a bikeshed and something that can have significant impact on salary, unfortunately. As long as non-technical recruiters are hiring based on buzzwords, it matters.
A science degree is not an engineering degree, and one is not practicing science in their hot startup. So, fair enough.
I think the label "software engineer" carries as much or as little meaning as "sailor" in a naval context.
A "sailor" could be a captain, cook, look-out, marconist, machinist, steward,... anyone who's enlisted on a ship doing a set of tasks to keep things going.
Is a technical writer a software engineer then? I would say so, yes. Why? Because they are involved in an intrinsic part of the entire process of building and maintaining a piece of software.
The problem with "software engineer" as you frame them, is that you also raise the bar to an incredibly high to attain level as things stand today. Why? Because of how the field has kept on compounding ever more complexity over the past decades. It's extremely hard for mere mortals to memorize a a vast and ever changing corpus of knowledge and experience, be able to dive deeply in any codebase and understand all the parts while also have time left to write detailed, readable and understandable technical documentation.
Case in point: Virtually everyone has a gazillion tabs open with an equal number of googled StackExchange posts.
To keep up with the analogy: I don't think the radio-operator will act as a navigator; and neither does the navigator know the fine details of how the innards of a radio look like.
Hence why you most software engineers are specialists in their trade. And often, specialists in a small fraction of the entire knowledge domain.
Regardless, software engineers are without a shred of doubt programmers. Programming is exactly that: feeding a Von Neumann machine a list of instructions in order to "make it do" something. No more, no less. It doesn't matter what your role is in that process - defining the problem, working on an instruction set, typing the instruction set into the machine, documenting the instruction set, verifying the output,... - you're basically a programmer.
The primary reason why we call ourselves "software engineers", really only is because Margret Hamilton - thé Margaret Hamilton of the Apollo AGC computer - came up with the label in order to legitimize the work she and her team did at NASA:
https://en.wikipedia.org/wiki/History_of_software_engineerin...
In fact, the rise of complexity has caused a "software crisis "in the late '60s to '80s. And it was named as such: a "software crisis":
https://en.wikipedia.org/wiki/Software_crisis
All that is old becomes new again. The more I read about the history of our discipline, the more I'm convinced that we are just chasing our own tails over and over again.
Arguing over who is a "programmer" and who is a "software engineer" is - ultimately - basically arguing over semantics and marketing.
At the end of the day, the world doesn't care how the pie was made. They simply want to be able to fly safe, watch TV and file their taxes efficiently.
A "sailor" could be a captain, cook, look-out, marconist, machinist, steward,... anyone who's enlisted on a ship doing a set of tasks to keep things going.
Is a technical writer a software engineer then? I would say so, yes. Why? Because they are involved in an intrinsic part of the entire process of building and maintaining a piece of software.
The problem with "software engineer" as you frame them, is that you also raise the bar to an incredibly high to attain level as things stand today. Why? Because of how the field has kept on compounding ever more complexity over the past decades. It's extremely hard for mere mortals to memorize a a vast and ever changing corpus of knowledge and experience, be able to dive deeply in any codebase and understand all the parts while also have time left to write detailed, readable and understandable technical documentation.
Case in point: Virtually everyone has a gazillion tabs open with an equal number of googled StackExchange posts.
To keep up with the analogy: I don't think the radio-operator will act as a navigator; and neither does the navigator know the fine details of how the innards of a radio look like.
Hence why you most software engineers are specialists in their trade. And often, specialists in a small fraction of the entire knowledge domain.
Regardless, software engineers are without a shred of doubt programmers. Programming is exactly that: feeding a Von Neumann machine a list of instructions in order to "make it do" something. No more, no less. It doesn't matter what your role is in that process - defining the problem, working on an instruction set, typing the instruction set into the machine, documenting the instruction set, verifying the output,... - you're basically a programmer.
The primary reason why we call ourselves "software engineers", really only is because Margret Hamilton - thé Margaret Hamilton of the Apollo AGC computer - came up with the label in order to legitimize the work she and her team did at NASA:
https://en.wikipedia.org/wiki/History_of_software_engineerin...
In fact, the rise of complexity has caused a "software crisis "in the late '60s to '80s. And it was named as such: a "software crisis":
https://en.wikipedia.org/wiki/Software_crisis
All that is old becomes new again. The more I read about the history of our discipline, the more I'm convinced that we are just chasing our own tails over and over again.
Arguing over who is a "programmer" and who is a "software engineer" is - ultimately - basically arguing over semantics and marketing.
At the end of the day, the world doesn't care how the pie was made. They simply want to be able to fly safe, watch TV and file their taxes efficiently.
“All that is old becomes new again. The more I read about the history of our discipline, the more I'm convinced that we are just chasing our own tails over and over again.”
It’s a curious thing about our industry: not only do we not learn from our mistakes, but we also don’t learn from our successes. – Keith Braithwaite
It’s a curious thing about our industry: not only do we not learn from our mistakes, but we also don’t learn from our successes. – Keith Braithwaite
"Before I learned the art, a punch was just a punch, and a kick, just a kick. After I learned the art, a punch was no longer a punch, a kick, no longer a kick. Now that I understand the art, a punch is just a punch and a kick is just a kick." - Bruce Lee
Re- the Emacs config suddenly breaking... I do something getting more and more common: I put my entire Emacs config in Git. It's a bit more work when upgrading packages (because you have to commit them too) but then there's hardly ever any breakage that's not one Git checkout away (I'd say anyway that Emacs doesn't that often break at all: it's more the usual package dependencies SNAFU of our trade that bites Emacs users once in a while when they upgrade this or that package).
On a funny side note I had a very bad Emacs breakage recently and at first couldn't understand why checking out the latest known correct Git version wasn't working on my main machine. It was working on another computer (btw copying my entire Emacs config is, well, also one git command away, so is backuping). Turns out: for whatever reason the file containing the list of files recently opened by Emacs got corrupted in a very strange way and that's one of the rare Emacs file I'm not committing into Git. Took me a few minutes to sort out.
On a funny side note I had a very bad Emacs breakage recently and at first couldn't understand why checking out the latest known correct Git version wasn't working on my main machine. It was working on another computer (btw copying my entire Emacs config is, well, also one git command away, so is backuping). Turns out: for whatever reason the file containing the list of files recently opened by Emacs got corrupted in a very strange way and that's one of the rare Emacs file I'm not committing into Git. Took me a few minutes to sort out.
For me, programming is difficult because once you reach a certain level of complexity it's very difficult to keep a robust enough model of the program in your head.
TDD has really helped me in this regard because it forces me to start building the model from ground up as opposed to in media res.
TDD has really helped me in this regard because it forces me to start building the model from ground up as opposed to in media res.
I find this article beautifully written and it resonated with me. Writing maintainable code is damn hard for larger projects.
Also, I read a couple comments above, and I feel that people who wrote them have no idea who Joe was. To me Joe is an inspiration, and I think his words are usually not there to be debated ;), after all he cocreated Erlang, and Erlang and the OTP is a masterpiece imo.
Also, I read a couple comments above, and I feel that people who wrote them have no idea who Joe was. To me Joe is an inspiration, and I think his words are usually not there to be debated ;), after all he cocreated Erlang, and Erlang and the OTP is a masterpiece imo.
"After a week of struggling with a broken LDAP sever written in C and badly documented I had a lapse of memory and forget that my boss said and accidentally implemented a server from scratch in Erlang during my lunch break."
Joe was awesome, on so many levels. You have to love the healthy rebellious streak and the talent to back it up.
Joe was awesome, on so many levels. You have to love the healthy rebellious streak and the talent to back it up.
It's kind of the worst of both worlds: it looks like it should be easy, but it's confoundingly difficult in ways that are impossible to see unless you're actually trying to practice it.
Given any non-deterministic problem, 98% programmers will treat it as a deterministic nail and hit it with their favorite C until one or both is dead.
Is this not true of most difficult things?
When I look at the high regard most people hold, say, lawyers and doctors in, who also do hard things (that are accepted as hard), I’d have to say no.
I agree that programming is difficult, but Im not sure he understands why he's finding it so difficult.
> "I Google a bit and after a while find a posting where some poor unfortunate soul has encountered exactly the same problem that I have. My heart leaps for joy. My trembling fingers enter the magic spell that will remove the curse, and ... nothing. The problem remains."
and
> "I'm lazy, I'm a good for nothing slacker. But when I want to put a diagram into LaTeX I don't want to have to read a 391 page manual first. Now I know you will accuse me of laziness and of being of unsound moral character,"
I wouldnt go so far as questioning his morality. But if you're not constantly focused on learning, even the minor details of the stacks you're working with, you'll increase the difficulty enormously. He sums up the danger of that attitude perfectly in his closing remark
> "Fortunately eleven minutes with the Google casino worked. The second suggestion of how to fix my problem worked - and I still don't know why emacs could not find aspell - and life is too short to find out why."
He's fixed it now. He has no idea what was wrong or how to arrive at a solution. Next time he faces, even the same problem, he'll be back on Google trying his luck.
> "I Google a bit and after a while find a posting where some poor unfortunate soul has encountered exactly the same problem that I have. My heart leaps for joy. My trembling fingers enter the magic spell that will remove the curse, and ... nothing. The problem remains."
and
> "I'm lazy, I'm a good for nothing slacker. But when I want to put a diagram into LaTeX I don't want to have to read a 391 page manual first. Now I know you will accuse me of laziness and of being of unsound moral character,"
I wouldnt go so far as questioning his morality. But if you're not constantly focused on learning, even the minor details of the stacks you're working with, you'll increase the difficulty enormously. He sums up the danger of that attitude perfectly in his closing remark
> "Fortunately eleven minutes with the Google casino worked. The second suggestion of how to fix my problem worked - and I still don't know why emacs could not find aspell - and life is too short to find out why."
He's fixed it now. He has no idea what was wrong or how to arrive at a solution. Next time he faces, even the same problem, he'll be back on Google trying his luck.
>Next time he faces, even the same problem, he'll be back on Google trying his luck.
There isn't a next time because Joe died last year.
I think you misunderstand the point. Time is truly limited thing you have in life, and you are using much of that time understanding minor tool that are not the major point of what you are trying to do, that doesn't seem productive and is indeed infuriating.
About the final mark, those eleven minutes should even be needed, things break unfortuntatly, and if who has deep understanding of every single tool you put your hands on, you will not have the time to do whatever you need to do.
A few years ago, I had the "pleasure" of have to use docker on windows, on a complex stack, the docker windows client was always breaking with the solution always being revert to previous version, wait issue fix, update. Ofc, before that we needed to waste some time to check if it was I who broke something or if it was an update. The lesson was, only update sporadically, which also has its downsides. Or should I instead have a deep understand on how docker for windows client worker and submitting the fix myself? Do you know if I had the time for it?
Too many things in our field are held by duct tape that is always tearing. I'm also culprit of that. But saying that because tools not being newbie friendly, or some tools breaking it's the fault of the user is not really a good a approach. Being a programmer shouldn't be about fixing your editor every time it breaks, or spend hours learning arcane tools that are not about programming.
There isn't a next time because Joe died last year.
I think you misunderstand the point. Time is truly limited thing you have in life, and you are using much of that time understanding minor tool that are not the major point of what you are trying to do, that doesn't seem productive and is indeed infuriating.
About the final mark, those eleven minutes should even be needed, things break unfortuntatly, and if who has deep understanding of every single tool you put your hands on, you will not have the time to do whatever you need to do.
A few years ago, I had the "pleasure" of have to use docker on windows, on a complex stack, the docker windows client was always breaking with the solution always being revert to previous version, wait issue fix, update. Ofc, before that we needed to waste some time to check if it was I who broke something or if it was an update. The lesson was, only update sporadically, which also has its downsides. Or should I instead have a deep understand on how docker for windows client worker and submitting the fix myself? Do you know if I had the time for it?
Too many things in our field are held by duct tape that is always tearing. I'm also culprit of that. But saying that because tools not being newbie friendly, or some tools breaking it's the fault of the user is not really a good a approach. Being a programmer shouldn't be about fixing your editor every time it breaks, or spend hours learning arcane tools that are not about programming.
Webdev seems to be a duct tape paradise full of beginner tutorials that go nowhere. And when the hard problems popup the suggestion is to google search instead of KISS. I dont know somethings will always be difficult.
[deleted]
The guy created the Erlang language. He probably has some idea what he’s talking about.
We could make everything easier on ourselves if we had more intelligent tools.
We build web pages to help us come up to speed quickly. For example,
https://learnxinyminutes.com/
But it would be better if our tools could bring us up to speed as we learn.
If we know one computer language well, shouldn’t a tool be able to guide us quickly to the syntax and idiomatic concepts in another language? We know many concepts:
Strings, collections, maps, arrays, sets, dates and times, functional concepts, sorting, regex, concurrency, ...
Basically, a cookbook of examples, etc.
I’m working on a Swift Cookbook to make it easier and faster for the next “guy” (person).
https://github.com/melling/SwiftCookBook/blob/master/README....
Ideally, in the future, the recipes are built into the editor.
You could ask “how to create a mutable map” then choose a computer language the get examples, etc.
Our tools should know the 1000 most common things we’d like to do and be ready to assist without requiring Google.
Our time is limited.
We could make everything easier on ourselves if we had more intelligent tools.
We build web pages to help us come up to speed quickly. For example,
https://learnxinyminutes.com/
But it would be better if our tools could bring us up to speed as we learn.
If we know one computer language well, shouldn’t a tool be able to guide us quickly to the syntax and idiomatic concepts in another language? We know many concepts:
Strings, collections, maps, arrays, sets, dates and times, functional concepts, sorting, regex, concurrency, ...
Basically, a cookbook of examples, etc.
I’m working on a Swift Cookbook to make it easier and faster for the next “guy” (person).
https://github.com/melling/SwiftCookBook/blob/master/README....
Ideally, in the future, the recipes are built into the editor.
You could ask “how to create a mutable map” then choose a computer language the get examples, etc.
Our tools should know the 1000 most common things we’d like to do and be ready to assist without requiring Google.
Our time is limited.
Joe Armstrong is the co-creator of erlang, so I'm pretty sure he knows why programming is difficult, he's just being personable and cheeky in this essay.
He's also got a habit of asking why and finding out (keep in mind by training he was a physics PhD), this essay notwithstanding.
He's also got a habit of asking why and finding out (keep in mind by training he was a physics PhD), this essay notwithstanding.
I do get that he was playing out a "persona" in the piece, and I was commenting on that persona.
You were commenting on the persona, but also stated "Im not sure he understands why he's finding it so difficult."
If you believe the statements he was making were rhetorical in nature, but are dismissive of them, while also crediting that as an individual he was insanely intelligent, with both a level of experience and a level of curiosity that outshines most of us...perhaps you missed the points he was making?
If you believe the statements he was making were rhetorical in nature, but are dismissive of them, while also crediting that as an individual he was insanely intelligent, with both a level of experience and a level of curiosity that outshines most of us...perhaps you missed the points he was making?
Well he does point at that issue, under time restrictions you cannot focus on the minutiae of every technology you work on. If you work in C++ all day maybe you have the time to learn 90% of the most common problems. But if you typeset in LaTeX once a year, it's a really bad investment of your time. If not finding aspell happened once in 10 years then it's also a bad investment of your time if it takes much longer to learn the why.
I'm a big fan of learning the why. But it only makes sense if you use the technology enough.
I'm a big fan of learning the why. But it only makes sense if you use the technology enough.
I agree, of course there are some practical concerns. I dont dig too deep into a BSOD memory error, I mostly just replace the block. But in general, I recommend following the rabbit hole just far enough to eliminate most surprises.
> I don't want to have to read a 391 page manual
I don’t have any problem with reading a 391 page manual first: I’ll come away with a solid understanding of what I’m doing, and I’ll be far more effective in the future. Reading the manual is an investment that pays off ten-fold in short order. The problem isn’t that I don’t want to read a manual, it’s that the “scrum master” breathing down my neck to increase my “velocity” and close tickets sees me reading the manual and says “why are you wasting time reading when you could just randomly google until you find a solution or interrupt your also busy coworkers with inane questions that they don’t really know the answers to either?”
I don’t have any problem with reading a 391 page manual first: I’ll come away with a solid understanding of what I’m doing, and I’ll be far more effective in the future. Reading the manual is an investment that pays off ten-fold in short order. The problem isn’t that I don’t want to read a manual, it’s that the “scrum master” breathing down my neck to increase my “velocity” and close tickets sees me reading the manual and says “why are you wasting time reading when you could just randomly google until you find a solution or interrupt your also busy coworkers with inane questions that they don’t really know the answers to either?”
Programmers should be, and indeed have to be, fundamentally lazy, to be any good. My entire goal in life is, and always has been, to get the shit that other people shovel onto my plate done as quickly and efficiently as I can, so I can get back to the much more interesting things that I'd rather be doing. A good programmer will go to great lengths to avoid doing time-consuming tedious bullshit.
With regards to fixing bullshit transient bugs in other people's software: usually understanding the full root cause does not matter. It's going to update, and bring forth a whole new suite of bugs and oddities in short order. Your machine is a weird, ungovernable collection of state that cannot be fully understood and rarely presents the same way twice. If I had a dollar for every time I followed the definition of insanity and did the same thing over and over to get different results, I wouldn't need to work anymore.
But when you have found a StackOverflow post that ends up working to fix some whack-a-mole stupid thing, it's not like you move on and that knowledge goes poof into the aether. You might forget some details of what it was, but the next time something along those lines comes up, there will at least be the trace of a memory of what fixed it the last time. Over time, you build up this pattern matching apparatus, and in a couple years you can look at a bizarre nested exception trace generated from deep inside some Javabean hell, and you know that, "Oh, something is wonky with DNS on this machine" or whatever. It looks like magic from the outside, but it is utterly mundane.
With regards to fixing bullshit transient bugs in other people's software: usually understanding the full root cause does not matter. It's going to update, and bring forth a whole new suite of bugs and oddities in short order. Your machine is a weird, ungovernable collection of state that cannot be fully understood and rarely presents the same way twice. If I had a dollar for every time I followed the definition of insanity and did the same thing over and over to get different results, I wouldn't need to work anymore.
But when you have found a StackOverflow post that ends up working to fix some whack-a-mole stupid thing, it's not like you move on and that knowledge goes poof into the aether. You might forget some details of what it was, but the next time something along those lines comes up, there will at least be the trace of a memory of what fixed it the last time. Over time, you build up this pattern matching apparatus, and in a couple years you can look at a bizarre nested exception trace generated from deep inside some Javabean hell, and you know that, "Oh, something is wonky with DNS on this machine" or whatever. It looks like magic from the outside, but it is utterly mundane.
[deleted]
Thats a modern age coding problem, copy it from google or stackoverflow and they dont know what they solved and how they solved it.
I'll look up things on stackoverflow/google, but I'll also read through the corresponding documentation in the man page or info document to gain a better understanding of the solution. Sometimes, I find a better way to do what I need after reading through the actual documentation.
I guess we could look at stackoverflow/google as a more sophisticated index rather than as a sole resource.
I guess we could look at stackoverflow/google as a more sophisticated index rather than as a sole resource.
[deleted]
> He's fixed it now. He has no idea what was wrong or how to arrive at a solution. Next time he faces, even the same problem, he'll be back on Google trying his luck.
Do it enough times and you will start to see patterns and gain an understanding - I would hope.
Do it enough times and you will start to see patterns and gain an understanding - I would hope.
Discussed at the time: https://news.ycombinator.com/item?id=7197255
2016: https://news.ycombinator.com/item?id=11002731
2019: https://news.ycombinator.com/item?id=19717877
2016: https://news.ycombinator.com/item?id=11002731
2019: https://news.ycombinator.com/item?id=19717877
Love this article! I don't think the guy is playing a 'persona' at all in this piece. These are the kinds of things he thinks about on a daily basis. Heck, these are the kinds of things I think about on a daily basis too, and I'm sure most devs who have been writing code for a few years do.
In my daily work, I don't have time to understand everything. There, i've said it. I'm not lazy. I'm not stupid. I just don't have time when I'm trying to get a task/job/chore done. I appreciate good abstraction/encapsulation. A good tool does this. A bad tool fails to do this. Same with documentation, really.
Don't get me started!:)
In my daily work, I don't have time to understand everything. There, i've said it. I'm not lazy. I'm not stupid. I just don't have time when I'm trying to get a task/job/chore done. I appreciate good abstraction/encapsulation. A good tool does this. A bad tool fails to do this. Same with documentation, really.
Don't get me started!:)
FYI Joe died last year and is best known for inventing Erlang.
https://en.m.wikipedia.org/wiki/Joe_Armstrong_(programmer)
https://en.m.wikipedia.org/wiki/Joe_Armstrong_(programmer)
I feel like the constraints he added are a bit too restrictive, they would force a program to be perfect whereas for most circumstances it would be enough for a program to be bug-free.
The real problem seems to be writing bug-free programs, which seems to be difficult mostly because it is hard to specify what a program should do formally (i.e. in code). Note that bugs are never about the program not doing what it is told, but are always a mismatch between the program and the programmers mental model of the program.
The real problem seems to be writing bug-free programs, which seems to be difficult mostly because it is hard to specify what a program should do formally (i.e. in code). Note that bugs are never about the program not doing what it is told, but are always a mismatch between the program and the programmers mental model of the program.
Not to mention, the program can be completely bug free but still terrible when put in real life because any one of the 10,000 things about its intended use was unknown or not prioritized.
My experience has been we have a big pile of complexity with some way of doing things. New shiny tech promises to eliminate this complexity. Perhaps it does, but also introduces new level of complexity. Old complexity hasn't fully vanished either, but now its problems have to be solved through the new level of complexity, resulting in a further emergent level of complexity.
Fortunately, there is a new shiny technology that will make all this complexity go away.
Fortunately, there is a new shiny technology that will make all this complexity go away.
Oh but many people will say it's child's play and management is where it's at. And then they you will have 10 people doing the work of 1.
- The output of the program is beautiful.
- The input to the program is beautiful.
- The program is beautiful.
I think it would make more sense if the word "beautiful" was replaced with the word "correct"...
It would also help strengthen his argument for why programming is so difficult!
- The input to the program is beautiful.
- The program is beautiful.
I think it would make more sense if the word "beautiful" was replaced with the word "correct"...
It would also help strengthen his argument for why programming is so difficult!
As a musician, writer, and programmer, my experience has been that beautiful is harder than correct.
Correctness is possible to verify (not always easy, ofc). You simply throw out the incorrect programs and that's it.
Then, what's left is a bunch of correct programs, stating the same, in very many very different ways.
Now you need to choose one of them. They're all "correct" - they produce required results when given particular input - but they obviously are not 100% equivalent.
What do you use, then, to choose one implementation out of all the others?
I think to call that quality "beauty" is fine. And that striving for it in your own programs is also right. Requiring it from others is a tricky subject, but as long as you don't go there, there's nothing wrong with talking about the beauty of code, programs, solutions, and so on.
Then, what's left is a bunch of correct programs, stating the same, in very many very different ways.
Now you need to choose one of them. They're all "correct" - they produce required results when given particular input - but they obviously are not 100% equivalent.
What do you use, then, to choose one implementation out of all the others?
I think to call that quality "beauty" is fine. And that striving for it in your own programs is also right. Requiring it from others is a tricky subject, but as long as you don't go there, there's nothing wrong with talking about the beauty of code, programs, solutions, and so on.
I suspect ie didn't specify correct because correctness is impossible; with the following constraint (i'm surprised he didn't have as the last bullet point): and it must run on top of an unreliable subsystem.
On top of several unreliable subsystems.
I think that's a big part of why it's so hard. You've got leaky, imperfectly understood, unreliable subsystems, and you're trying to build the best system you can on top of it. And what you produce inevitably is a leaky, imperfectly understood, unreliable system... which becomes somebody else's subsystem. And so it goes.
You say: We need to create perfect subsystems! Formal verification (or robust type systems, or better requirements, or mathematical reasoning, or some other approach) will save us! But it's not that simple. It starts clear down at the hardware level. How much can you formally prove about your CPU? After taking into account it's errata sheet? The union of the errata sheets of all the revs of the CPU? If you're running on PCs, the errata sheets of every CPU that anybody could conceivably be running on?
If you can't formally prove much about the CPU, how are you going to formally prove the OS and/or compiler? And if you can't formally prove those, how can you formally prove anything else?
It's leaky, unreliable, incompletely understood subsystems all the way down.
I think that's a big part of why it's so hard. You've got leaky, imperfectly understood, unreliable subsystems, and you're trying to build the best system you can on top of it. And what you produce inevitably is a leaky, imperfectly understood, unreliable system... which becomes somebody else's subsystem. And so it goes.
You say: We need to create perfect subsystems! Formal verification (or robust type systems, or better requirements, or mathematical reasoning, or some other approach) will save us! But it's not that simple. It starts clear down at the hardware level. How much can you formally prove about your CPU? After taking into account it's errata sheet? The union of the errata sheets of all the revs of the CPU? If you're running on PCs, the errata sheets of every CPU that anybody could conceivably be running on?
If you can't formally prove much about the CPU, how are you going to formally prove the OS and/or compiler? And if you can't formally prove those, how can you formally prove anything else?
It's leaky, unreliable, incompletely understood subsystems all the way down.
All the way down to quantum mechanics, unfortunately.
I think I'll start using the phrase "Google Casino" now.
Technology jumping based on anecdotal evidence of the efficacy of doing so. Jumping around so often precludes a lot of practitioners from gaining a deep experience and understanding with the tools they're working with. This may be the only industry I know where pertinent knowledge and experience matters little.
The notion of "Full Stack Developers" gives the impression that one can be proficient top to bottom. What I find interesting about the label is full seems to usually be bounded on the lower end at a place much higher than a place where I would use the term full. This is one of the many areas in our industry where hubris is in play. Specialization is usually preferable for quality and scaling.
Real world business continually drives the fast and cheap legs of the stool to be chosen by management. However, I think this grates against most practitioners who not only care about quality but would admit, the aspect of quality is one of the major reasons they are even in the field to begin with. There is a large natural tension at play here. I think it's this tension that Joe was articulating.
It's seems to me the most satisfied folks in this field are the ones fortunate enough to be compensated for working within a bounded context where over time they can gain more and more experience and knowledge. This naturally leads to a growing confidence and a sense of control over the context with which they work.