6 ms·

Twilight of the programmers?

85 points by signa11 3y ago

Kinrany 3y ago
Doesn't sound all that different from other professions. When a client asks for something logically impossible, it's a case of them not being as good at creating logically consistent models. The domain is about as irrelevant as whether the totaled car was going to work or to a birthday party.
- DanielBMarkham 3y ago
  The difference is in the level-of-detail. Humans can't create logically-consistent models in-depth, no matter what the domain. Programmers, at least old-school domain-model-driven programmers, live in a world of constantly reminding people of this. Put differently, "logically-impossible" is a relative term. It's relative to human intelligence, not domain area. This is much akin to chess, where really smart people may be able to track a dozen or so symbols in a mostly-consistent way while others may just track a few. But nobody tracks 50, at least without some sort of logically-consistent computational domain model.
  - jrumbut 3y ago
    So the key difference is that in law, the state enforces an outcome whether it's logically consistent or not, in medicine death enforces an outcome in all cases, but in computer programming if something is illogical you have to deal with it on its own terms (either fix the world and start collecting vehicle mileage monthly or give up on the report)?
    - DanielBMarkham 3y ago
      Yes. Another way of stating that is that all professions (aside from math-based ones) are inconsistent at some level of detail and have various workarounds for that. Even accountants are paid to give "accounting opinions" about the various legalities and appropriate nature of the books. Looking across a bunch of domains, once you get people involved, around the edges of the problem domain accumulates a lot of fluff that for throughout history didn't matter. It still might not matter. Or maybe it does. We're the first to spot it.
      - Verdex 3y ago
        From what I can see, I agree with your point here. I've had a parallel thought for a few years now. Historically, if you wanted something done and you weren't going to do it yourself, you needed to find someone else to do it for you. Imprinting the exact specification of what you wanted them to do is impossible, so you give them some highlights, explain some edge cases, and make sure they understand the high level and off they go to do ... something. They'll figure it out I'm sure. For simple work, anyone would do. For complex work, it pays to have hard nosed managers with good memories who aren't afraid to yell at people 'slacking off'. And for the truly difficult work you need aged experts who trained under the best for decades and have practiced for decades more (and who have their own students following them wherever they went). So we have all sorts of skills and traditions for explaining to people what we want to happen. Explaining to a box of sand and copper on the other hand .... exposes some logical flaws that simply did not exist before.
    - mejutoco 3y ago
      The company going bankrupt could be the equivalent to death in medicine. I think you hit a good analogy with medicine, since death is not the only bad scenario. Following this analogy, technical debt could be akin to having to medicate for life.
  - DaiPlusPlus 3y ago
    > Humans can't create logically-consistent models in-depth Please clarify what you mean by a "logically-consistent model", and please explain what you consider constitutes an "in-depth" model. Can you give some concrete examples of this?
  - tempodox 3y ago
    > Humans can't create logically-consistent models in-depth, no matter what the domain. One of those inconvenient truths. I've found in my practice that computers, to a degree, can be a crutch that helps with that. Once your model becomes inconsistent, your program will stop working properly, whether you noticed the inconsistency yourself or not.
Michelangelo11 3y ago
The explanation in the article didn't really click for me, and I still don't fully understand why, according to the author, programming is so special compared to law, medicine, etc. I do of course understand why a given request from the client might be impossible to satisfy, given the abstractions that are currently in the code, but at least in some cases you can feasibly tweak the abstractions or build new ones. OK, that's not always possible, but ... so what? So, as far as I can see, the only conclusion left to draw is "Abstractions of a given subject can be mutually exclusive." OK ... and? Surely that's Logic 101. After all, they're abstractions and by definition they remove some information that's present in the subject itself, which means that information that's present in some abstractions of the subject won't be present in different ones.
- DanielBMarkham 3y ago
  That's true in a universal sense, but humans don't exist in a universally-logical world. Yes, all code/abstractions are broken, ie, all models are broken but some are more useful than others. That, however, is not the point. The point is that these models are inconsistent in an invisible way even to experienced practitioners in whatever domain the code is in. It's not the the code or abstraction is broken. As you say, that's a non-event. It's that the code can show where the people are broken in ways that they themselves do not understand. That's the new part. That's where the line about the code talking back to the people comes from in the essay. An abstraction is a person generalizing and codifying something. This is about code correcting abstractions, not abstractions being more or less useful than one another. I believe your directional arrow here is backward from the intent of the essay.
  - Michelangelo11 3y ago
    > It's that the code can show where the people are broken in ways that they themselves do not understand. Sorry, but I really don't understand how that's the case. Can you give a concrete example? I know you gave an example in the essay, but you didn't go into the specifics and you explicitly said its details don't matter and the reader shouldn't look at them closely.
mikewarot 3y ago
In the past when someone asked for something impossible, I offered up the closest possible work arounds, and let them choose. I give them all the detail they need (but no more) to understand what the limitations are if they ask why it's impossible. They have jobs to do, that were possible before things got automated, they should remain possible afterwards.
- JohnMakin 3y ago
  I do the same, but sometimes you enter this neverending scope creep in trying to satisfy the original request. Example - At one of my former jobs, management became concerned about developer productiveness. I was tasked with creating a UI + backend that would scrape our bitbucket repositories, and output a coder's commit history, LOC, and some other stuff. I quickly ran into an issue. This company had over 700 repositories - and by my estimate, added about 20 new ones every quarter (it was a large company with an absolutely massive codebase). Well, even doing a scan of ALL repositories would quickly eat up my rate limit with the API, so I came back to the stakeholders and told them what they were asking was pretty much impossible with the current limitations of the API. "Can't you build a cache? or a database? or scrape it yourself?" Ok, sure. Iteration 2 I built a database and queried it for the answers the users wanted. It spun into me creating nightly jobs that would scrape repositories and create this massive cache. Then the stakeholders began complaining about "diffs" of several hours - up to 1 business day - and I again ran into limitations with rate limiting. So that led me to try to make the caching system "smarter" and only archiving "hot" repos, and so on and so forth. In the end, of course, they didn't like the look/feel of the UI and scrapped the project after several months and I took a performance hit for it. Probably for the best, I know what they wanted to use that tool for (filtering devs by arbitrary "productivity" standards) and it should've died at the vine.
  - ryandrake 3y ago
    This is a constant problem when managing the expectations of product owners or stakeholders. You tell them "X is not possible, but I can give you Y with Z drawbacks/risks." They say, "Yes let's do that." and when you do, the first thing they say is "Great, but I noticed Z drawbacks happened. Can we fix those?" Arrrrgggghhhhhh....
JohnMakin 3y ago
In an ideal world product/project manager types are supposed to suss out these impossible requirements before they even make it to the programmer, but I'm still astounded at the amount of times in my career I'm either asked to do something impossible, suicidal, or flat out wrong. I always just imagined it was the same in other professions, but upon thinking further after reading this, I guess it might not be the case.
- Mizoguchi 3y ago
  I don't think that's the job of project managers. They are there to keep the project within scope, schedule and budget, find the resources you need and remove distractions so that you can focus on your craft. At least in my experience, it is expected that the lead or senior software engineer deals with the requirements, identifying missing, incomplete or out of scope items and communicate any issues to the PM so they can be discussed/negotiated with the customer or end user. Some of my best PMs don't even know much about software engineering.
lambdasquirrel 3y ago
I don’t know if I’d agree just yet. In the past, I’ve generally found that the better I got at something, the less time I spent in it. The better that I got at coding, for example, the more time I’d have to spend (proportionally) in ops, design, marketing, etc., all the things that weren’t coding. I think that the better that AI gets at churning out the dumb stuff, the more that we’ll actually spend time on interesting things. I think the real hazard is that indeed, people will churn out lots of dumb stuff. AI can write lots of code. Can it accurately read lots of its own code? I think the difficulty in managing a large code base is what will keep people writing actual code.
- immibis 3y ago
  We can consider the history of self-programming computers to see how this plays out. The first self-programming computer system was called an "assembler". Later ones were called "compilers". It played out about how you have predicted.
antisthenes 3y ago
> I firmly believe that there was something very, very important there. Something we're losing. Yeah, it's called critical thinking. There's a lot of people that lucked into a lot of money, but without the critical thinking skills to understand their own survivor bias or that the world where they merited such a windfall does not, in fact, exist. > Neither you nor the person you were helping had any idea of how this was all going to work out, and that was just fine. It always worked out, and you always got paid. Mostly. This is false. You actually knew exactly how it was going to work out, because if you got to the point of framing out the problem, you already performed the required analysis. You want to know what happened? You solved it. You won. You automated the drudgery, but the way capitalism and public companies are designed is that you need to keep chasing returns on capital. Returns that aren't there anymore because of the law of diminishing returns. So what do you do? You invent a world where those returns exist. Of course they don't, and the world itself doesn't exist. But you have to invent it to make shareholders and all the workers believe that it does. So there goes your critical thinking out of the window.
schnable 3y ago
Sure, but the role of structured analysis is also done by Product Managers and Architects - if we end up in a world of AI code monkeys, the work shifts to these roles, themselves also assisted by AI.
luxuryballs 3y ago
This mismatching reality thing is a super common phenomenon in software dev and I think it’s key to internalize that there is often a shockingly big (and acceptable) difference between “the amount a perceived world needs to match the real world to be technically accurate” vs. “the amount the perceived world needs to match the real world in order to be good enough” AND, even more bewildering, very often the “good enough” difference version is the only one that can reach the goal of the software!
__MatrixMan__ 3y ago
I think that what we're losing is a habit of mapping our squishy human desires onto a formal system. Maybe you didn't chose a toolchain that treats it as a formal system. There isn't a proof assistant to be seen for miles in any direction. But when the guy says "give me foo" and you say "that's impossible", you're consulting a formal system and translating a proof back into that squishy human desire language. The author is maybe a bit too attached to the idea that the system is an ideal representation of the real world. Given a landscape of systems that might represent it, probably there's one that lets you give the guy what he wants, and probably it's not the one you've built. Spend enough time building something and it changes how you see the world, so that's an expected bias. I agree that it's a loss. The statistical approach used by AI's or by any sufficiently complex system of customer facing employees (which likely isolates the customer from the programmer) tends towards creating responses that are likely to make the guy go away, which is not always the same as responses that gave him what he asked for.
StillBored 3y ago
The idea is right, but his vin example is poor. If the system doesn't actually reflect reality than the system is poor. A better example might be someone say asking for a report that shows all the part time employees that are getting overtime time and a half pay. Which makes sense at first, until you consider that an employee working more than 30 hours (or whatever the number is) is classified as full time, and its not possible to get overtime unless your working more than 40 hours. So the programmer then has to go back and clarify, "do you want to find employees that were hired as part time but are now classified as full time, or are you interested in part time employees collecting holiday/danger/etc pay multipliers?" Saying "it can't be done" is the kind of thing you would get from a junior employee that doesn't understand the business nor the code. The more senior guy understands the mismatch and asks questions that clarify what the intentions actually are. So, the VIN example would make more sense if they clarified the system only has license plate data, and partial or missing VIN information because the data wasn't collected. In that case the work item includes getting someone to do that data entry/etc work of assuring the VINs exist for all the vehicles as well as creating the vin->mileage report.
- SoftTalker 3y ago
  You might also have employees who are ostensibly "part time" and average 30 hours a week but occasionally work more than 40 and get overtime pay. The real world is full of messiness like this, because what people actually do on a given day is rarely physically constrained by policies and job classifications.
  - treeman79 3y ago
    Recall during the dot com crash at RadioShack. District manager kept complaining that a bunch of displays were not getting setup. We were a busy understaffed store so nothing got done during the day. Finally I stayed until 3am once and got everything done. District was unhappy that I got extra pay. No thanks at all for resolving the matter.
    - advael 3y ago
taylodl 3y ago
What this Daniel Markham has done is describe the job of software architects. Software architects are supposed to keep the business from logically painting themselves into a corner. They look beyond the current project and the current requirements to ensure a system is being built that can be used to easily solve future business needs. It's a thankless job because you're saving people's butts years from now. Fortunately, I've been at this long enough and have saved people's butts enough times they think I'm prescient. Nope. I just think things through. All the way through. Beyond what you're asking right here and now.
- dianeb 3y ago
  Actually, it's also the job of lead or senior engineers who have to teach their experienced and educated teammates how to read and write a state diagram and how to use it in order to show them why the code/service in question is unreachable from the current state -- and should remain so.
- dasil003 3y ago
  It's not thankless if you have solid engineers and engineering managers. And if you don't have those things (at least somewhat), they're liable to make a complete mess of things regardless of how good your high-level design is. Good macro engineering vision can't be realized without good micro engineering.
proc0 3y ago
> Our profession does structured analysis in a way no other profession has ever done. Yes, it's because if you go and ask most software companies what engineers are supposed to do, the priorities have more to do with business than with computer science. If instead it worked like other industries, engineers would be expected to focus on software ONLY. There's no right way to do it of course, however I do think there is a lot of value (even business value) that is lost when engineers have non-technical responsibilities because it misses the point of engineering, which is to have machines solve problems.
shove 3y ago
The law example is kindof funny to me because my attorney and I get into these discussions that boil down to “yes, you’re right—the Constitution absolutely does say what you think it says about your civil rights, but that’s irrelevant. The judge is still going to convict you and you can appeal it all the way to SCOTUS and you’re going to loose every time.”
- voz_ 3y ago
  What is it with people misspelling lose lately?
baerrie 3y ago
Basically, modeling real life means modeling something that is at this very moment, unknowable and from many perspectives, paradoxical. Law and medicine are walled gardens of focus where paradox is filtered out (to a debilitating degree often) to solve specialized problems. We are tasked with using flexible machines to solve general problems, many of which are beyond absolute solutions.
photochemsyn 3y ago
Computers used to be humans skilled in doing careful painstaking calculations for clients that were guaranteed not to contain arithmetical mistakes (which would ruin the computer's reputation). Computers had aids like log tables to do multiplications via the process of addition and so on, with slide rules coming into play more recently. Programmers are currently humans skilled in the careful painstaking generation of code to accomplish specific tasks, but in the future programmers might be complex AI systems. However, some humans who understand both computation and programming will be required to talk to people who want these services but who don't know how to interact with the programmers and their computers. Where this is all going is an interesting question... will general AI systems arise that are capable of making their own decisions about what goals the programmers and computers should be targeted on?
ajani 3y ago
I'm more impressed with his giant signature at the end of the post, than the post itself.
tempodox 3y ago
By and large, I agree with the author's observations. > I think some of the best programs were essays, in the sense that the authors didn't know when they started exactly what they were trying to write. That's the premise that Lisp was built upon. As far as I know it's the only programming system that comes with the intention to let you write “essays”. All the other languages I know are targeted more narrowly.
pjdkoch 3y ago
Gödel is snickering in his grave.

85 points by signa11 3y ago

Doesn't sound all that different from other professions. When a client asks for something logically impossible, it's a case of them not being as good at creating logically consistent models. The domain is about as irrelevant as whether the totaled car was going to work or to a birthday party.

DanielBMarkham 3y ago
The difference is in the level-of-detail. Humans can't create logically-consistent models in-depth, no matter what the domain. Programmers, at least old-school domain-model-driven programmers, live in a world of constantly reminding people of this. Put differently, "logically-impossible" is a relative term. It's relative to human intelligence, not domain area. This is much akin to chess, where really smart people may be able to track a dozen or so symbols in a mostly-consistent way while others may just track a few. But nobody tracks 50, at least without some sort of logically-consistent computational domain model.
- jrumbut 3y ago
  So the key difference is that in law, the state enforces an outcome whether it's logically consistent or not, in medicine death enforces an outcome in all cases, but in computer programming if something is illogical you have to deal with it on its own terms (either fix the world and start collecting vehicle mileage monthly or give up on the report)?
  - DanielBMarkham 3y ago
    Yes. Another way of stating that is that all professions (aside from math-based ones) are inconsistent at some level of detail and have various workarounds for that. Even accountants are paid to give "accounting opinions" about the various legalities and appropriate nature of the books. Looking across a bunch of domains, once you get people involved, around the edges of the problem domain accumulates a lot of fluff that for throughout history didn't matter. It still might not matter. Or maybe it does. We're the first to spot it.
    - Verdex 3y ago
      From what I can see, I agree with your point here. I've had a parallel thought for a few years now. Historically, if you wanted something done and you weren't going to do it yourself, you needed to find someone else to do it for you. Imprinting the exact specification of what you wanted them to do is impossible, so you give them some highlights, explain some edge cases, and make sure they understand the high level and off they go to do ... something. They'll figure it out I'm sure. For simple work, anyone would do. For complex work, it pays to have hard nosed managers with good memories who aren't afraid to yell at people 'slacking off'. And for the truly difficult work you need aged experts who trained under the best for decades and have practiced for decades more (and who have their own students following them wherever they went). So we have all sorts of skills and traditions for explaining to people what we want to happen. Explaining to a box of sand and copper on the other hand .... exposes some logical flaws that simply did not exist before.
  - mejutoco 3y ago
    The company going bankrupt could be the equivalent to death in medicine. I think you hit a good analogy with medicine, since death is not the only bad scenario. Following this analogy, technical debt could be akin to having to medicate for life.
- DaiPlusPlus 3y ago
  > Humans can't create logically-consistent models in-depth Please clarify what you mean by a "logically-consistent model", and please explain what you consider constitutes an "in-depth" model. Can you give some concrete examples of this?
- tempodox 3y ago
  > Humans can't create logically-consistent models in-depth, no matter what the domain. One of those inconvenient truths. I've found in my practice that computers, to a degree, can be a crutch that helps with that. Once your model becomes inconsistent, your program will stop working properly, whether you noticed the inconsistency yourself or not.

Michelangelo11 3y ago

The explanation in the article didn't really click for me, and I still don't fully understand why, according to the author, programming is so special compared to law, medicine, etc. I do of course understand why a given request from the client might be impossible to satisfy, given the abstractions that are currently in the code, but at least in some cases you can feasibly tweak the abstractions or build new ones. OK, that's not always possible, but ... so what? So, as far as I can see, the only conclusion left to draw is "Abstractions of a given subject can be mutually exclusive." OK ... and? Surely that's Logic 101. After all, they're abstractions and by definition they remove some information that's present in the subject itself, which means that information that's present in some abstractions of the subject won't be present in different ones.

DanielBMarkham 3y ago
That's true in a universal sense, but humans don't exist in a universally-logical world. Yes, all code/abstractions are broken, ie, all models are broken but some are more useful than others. That, however, is not the point. The point is that these models are inconsistent in an invisible way even to experienced practitioners in whatever domain the code is in. It's not the the code or abstraction is broken. As you say, that's a non-event. It's that the code can show where the people are broken in ways that they themselves do not understand. That's the new part. That's where the line about the code talking back to the people comes from in the essay. An abstraction is a person generalizing and codifying something. This is about code correcting abstractions, not abstractions being more or less useful than one another. I believe your directional arrow here is backward from the intent of the essay.
- Michelangelo11 3y ago
  > It's that the code can show where the people are broken in ways that they themselves do not understand. Sorry, but I really don't understand how that's the case. Can you give a concrete example? I know you gave an example in the essay, but you didn't go into the specifics and you explicitly said its details don't matter and the reader shouldn't look at them closely.

mikewarot 3y ago

In the past when someone asked for something impossible, I offered up the closest possible work arounds, and let them choose. I give them all the detail they need (but no more) to understand what the limitations are if they ask why it's impossible. They have jobs to do, that were possible before things got automated, they should remain possible afterwards.

JohnMakin 3y ago
I do the same, but sometimes you enter this neverending scope creep in trying to satisfy the original request. Example - At one of my former jobs, management became concerned about developer productiveness. I was tasked with creating a UI + backend that would scrape our bitbucket repositories, and output a coder's commit history, LOC, and some other stuff. I quickly ran into an issue. This company had over 700 repositories - and by my estimate, added about 20 new ones every quarter (it was a large company with an absolutely massive codebase). Well, even doing a scan of ALL repositories would quickly eat up my rate limit with the API, so I came back to the stakeholders and told them what they were asking was pretty much impossible with the current limitations of the API. "Can't you build a cache? or a database? or scrape it yourself?" Ok, sure. Iteration 2 I built a database and queried it for the answers the users wanted. It spun into me creating nightly jobs that would scrape repositories and create this massive cache. Then the stakeholders began complaining about "diffs" of several hours - up to 1 business day - and I again ran into limitations with rate limiting. So that led me to try to make the caching system "smarter" and only archiving "hot" repos, and so on and so forth. In the end, of course, they didn't like the look/feel of the UI and scrapped the project after several months and I took a performance hit for it. Probably for the best, I know what they wanted to use that tool for (filtering devs by arbitrary "productivity" standards) and it should've died at the vine.
- ryandrake 3y ago
  This is a constant problem when managing the expectations of product owners or stakeholders. You tell them "X is not possible, but I can give you Y with Z drawbacks/risks." They say, "Yes let's do that." and when you do, the first thing they say is "Great, but I noticed Z drawbacks happened. Can we fix those?" Arrrrgggghhhhhh....

JohnMakin 3y ago

In an ideal world product/project manager types are supposed to suss out these impossible requirements before they even make it to the programmer, but I'm still astounded at the amount of times in my career I'm either asked to do something impossible, suicidal, or flat out wrong. I always just imagined it was the same in other professions, but upon thinking further after reading this, I guess it might not be the case.

Mizoguchi 3y ago
I don't think that's the job of project managers. They are there to keep the project within scope, schedule and budget, find the resources you need and remove distractions so that you can focus on your craft. At least in my experience, it is expected that the lead or senior software engineer deals with the requirements, identifying missing, incomplete or out of scope items and communicate any issues to the PM so they can be discussed/negotiated with the customer or end user. Some of my best PMs don't even know much about software engineering.

lambdasquirrel 3y ago

I don’t know if I’d agree just yet. In the past, I’ve generally found that the better I got at something, the less time I spent in it. The better that I got at coding, for example, the more time I’d have to spend (proportionally) in ops, design, marketing, etc., all the things that weren’t coding. I think that the better that AI gets at churning out the dumb stuff, the more that we’ll actually spend time on interesting things. I think the real hazard is that indeed, people will churn out lots of dumb stuff. AI can write lots of code. Can it accurately read lots of its own code? I think the difficulty in managing a large code base is what will keep people writing actual code.

immibis 3y ago
We can consider the history of self-programming computers to see how this plays out. The first self-programming computer system was called an "assembler". Later ones were called "compilers". It played out about how you have predicted.

antisthenes 3y ago

> I firmly believe that there was something very, very important there. Something we're losing. Yeah, it's called critical thinking. There's a lot of people that lucked into a lot of money, but without the critical thinking skills to understand their own survivor bias or that the world where they merited such a windfall does not, in fact, exist. > Neither you nor the person you were helping had any idea of how this was all going to work out, and that was just fine. It always worked out, and you always got paid. Mostly. This is false. You actually knew exactly how it was going to work out, because if you got to the point of framing out the problem, you already performed the required analysis. You want to know what happened? You solved it. You won. You automated the drudgery, but the way capitalism and public companies are designed is that you need to keep chasing returns on capital. Returns that aren't there anymore because of the law of diminishing returns. So what do you do? You invent a world where those returns exist. Of course they don't, and the world itself doesn't exist. But you have to invent it to make shareholders and all the workers believe that it does. So there goes your critical thinking out of the window.

schnable 3y ago

Sure, but the role of structured analysis is also done by Product Managers and Architects - if we end up in a world of AI code monkeys, the work shifts to these roles, themselves also assisted by AI.

luxuryballs 3y ago

This mismatching reality thing is a super common phenomenon in software dev and I think it’s key to internalize that there is often a shockingly big (and acceptable) difference between “the amount a perceived world needs to match the real world to be technically accurate” vs. “the amount the perceived world needs to match the real world in order to be good enough” AND, even more bewildering, very often the “good enough” difference version is the only one that can reach the goal of the software!

__MatrixMan__ 3y ago

I think that what we're losing is a habit of mapping our squishy human desires onto a formal system. Maybe you didn't chose a toolchain that treats it as a formal system. There isn't a proof assistant to be seen for miles in any direction. But when the guy says "give me foo" and you say "that's impossible", you're consulting a formal system and translating a proof back into that squishy human desire language. The author is maybe a bit too attached to the idea that the system is an ideal representation of the real world. Given a landscape of systems that might represent it, probably there's one that lets you give the guy what he wants, and probably it's not the one you've built. Spend enough time building something and it changes how you see the world, so that's an expected bias. I agree that it's a loss. The statistical approach used by AI's or by any sufficiently complex system of customer facing employees (which likely isolates the customer from the programmer) tends towards creating responses that are likely to make the guy go away, which is not always the same as responses that gave him what he asked for.

StillBored 3y ago

The idea is right, but his vin example is poor. If the system doesn't actually reflect reality than the system is poor. A better example might be someone say asking for a report that shows all the part time employees that are getting overtime time and a half pay. Which makes sense at first, until you consider that an employee working more than 30 hours (or whatever the number is) is classified as full time, and its not possible to get overtime unless your working more than 40 hours. So the programmer then has to go back and clarify, "do you want to find employees that were hired as part time but are now classified as full time, or are you interested in part time employees collecting holiday/danger/etc pay multipliers?" Saying "it can't be done" is the kind of thing you would get from a junior employee that doesn't understand the business nor the code. The more senior guy understands the mismatch and asks questions that clarify what the intentions actually are. So, the VIN example would make more sense if they clarified the system only has license plate data, and partial or missing VIN information because the data wasn't collected. In that case the work item includes getting someone to do that data entry/etc work of assuring the VINs exist for all the vehicles as well as creating the vin->mileage report.

SoftTalker 3y ago
You might also have employees who are ostensibly "part time" and average 30 hours a week but occasionally work more than 40 and get overtime pay. The real world is full of messiness like this, because what people actually do on a given day is rarely physically constrained by policies and job classifications.
- treeman79 3y ago
  Recall during the dot com crash at RadioShack. District manager kept complaining that a bunch of displays were not getting setup. We were a busy understaffed store so nothing got done during the day. Finally I stayed until 3am once and got everything done. District was unhappy that I got extra pay. No thanks at all for resolving the matter.
  - advael 3y ago

taylodl 3y ago

What this Daniel Markham has done is describe the job of software architects. Software architects are supposed to keep the business from logically painting themselves into a corner. They look beyond the current project and the current requirements to ensure a system is being built that can be used to easily solve future business needs. It's a thankless job because you're saving people's butts years from now. Fortunately, I've been at this long enough and have saved people's butts enough times they think I'm prescient. Nope. I just think things through. All the way through. Beyond what you're asking right here and now.

dianeb 3y ago
Actually, it's also the job of lead or senior engineers who have to teach their experienced and educated teammates how to read and write a state diagram and how to use it in order to show them why the code/service in question is unreachable from the current state -- and should remain so.
dasil003 3y ago
It's not thankless if you have solid engineers and engineering managers. And if you don't have those things (at least somewhat), they're liable to make a complete mess of things regardless of how good your high-level design is. Good macro engineering vision can't be realized without good micro engineering.

proc0 3y ago

> Our profession does structured analysis in a way no other profession has ever done. Yes, it's because if you go and ask most software companies what engineers are supposed to do, the priorities have more to do with business than with computer science. If instead it worked like other industries, engineers would be expected to focus on software ONLY. There's no right way to do it of course, however I do think there is a lot of value (even business value) that is lost when engineers have non-technical responsibilities because it misses the point of engineering, which is to have machines solve problems.

shove 3y ago

The law example is kindof funny to me because my attorney and I get into these discussions that boil down to “yes, you’re right—the Constitution absolutely does say what you think it says about your civil rights, but that’s irrelevant. The judge is still going to convict you and you can appeal it all the way to SCOTUS and you’re going to loose every time.”

voz_ 3y ago
What is it with people misspelling lose lately?

baerrie 3y ago

Basically, modeling real life means modeling something that is at this very moment, unknowable and from many perspectives, paradoxical. Law and medicine are walled gardens of focus where paradox is filtered out (to a debilitating degree often) to solve specialized problems. We are tasked with using flexible machines to solve general problems, many of which are beyond absolute solutions.

photochemsyn 3y ago

Computers used to be humans skilled in doing careful painstaking calculations for clients that were guaranteed not to contain arithmetical mistakes (which would ruin the computer's reputation). Computers had aids like log tables to do multiplications via the process of addition and so on, with slide rules coming into play more recently. Programmers are currently humans skilled in the careful painstaking generation of code to accomplish specific tasks, but in the future programmers might be complex AI systems. However, some humans who understand both computation and programming will be required to talk to people who want these services but who don't know how to interact with the programmers and their computers. Where this is all going is an interesting question... will general AI systems arise that are capable of making their own decisions about what goals the programmers and computers should be targeted on?

ajani 3y ago

I'm more impressed with his giant signature at the end of the post, than the post itself.

tempodox 3y ago

By and large, I agree with the author's observations. > I think some of the best programs were essays, in the sense that the authors didn't know when they started exactly what they were trying to write. That's the premise that Lisp was built upon. As far as I know it's the only programming system that comes with the intention to let you write “essays”. All the other languages I know are targeted more narrowly.

pjdkoch 3y ago

Gödel is snickering in his grave.