Programmers should not be empowered to perform roles for which they are an ill fit. In general, programmers are detailists who speak the language of the computer; they do not have a big-picture perspective nor do they understand the problem in business terms. Their social skills are very often lacking, and they are prone to arrogance. In a high-functioning information systems organization, the programmer's job is one of simple translation from specifications into code; those specifications will have been produced via stepwise refinement by systems analysts who do understand the business and the people within it.
See the late Tim Bryce's Theory P essay: https://www.phmainstreet.com/mba/ss050117.pdf and note that he uses the exact same "artists vs. house painters" analogy. Before his retirement Tim had been managing large software projects since before much of Hackernews was born, and had forgotten more than most internet commenters know about what it takes to manage a successful project.
The "software businesses where true creation is happening" are few and far between -- Apple, maybe Google at its peak, and a handful of others. They are run by geniuses, typically from top-tier schools like MIT and Stanford. They are not the typical software organization. The typical software organization produces the software that keeps civilization humming -- and doing that is a proven, teachable, scientific process. Lately we've seen many organizations that should be doing this instead cosplaying as a bunch of genius disruptors, but they have nowhere near the brainpower to actually pull it off, and the world has gone to hell in a handbasket as a result.
Maybe, just maybe, you're mixing cause and effect.
If you treat developers like house painters, they will not give you more. They will build the spec that you give them, and hold their tongues when they know it's a bad user experience.
If you treat developers like co-creators, and hire explicitly, and you put them in the same room with customers, you get a group thinking about how to solve a problem that your users have. They may be able to deliver something quicker, or develop a better customer experience, or question assumptions that lead to a better product.
An empowered engineer will be able to ask, "but what about how this user uses the software? Will this work for them?" And they become great at that by getting experience doing this - it's a skill, not an inborn talent.
Precisely, I've worked at a couple of places where software developers were treated like assembly line workers who convert tickets into code, and on one occasion I was even told that it wasn't my job to ask questions designed to improve my big-picture understanding of the problem, use-cases, etc.
I feel like the "programmers only care about code" trope is perpetuated by people who aren't good at sharing knowledge, or who lack intimate understanding of their customers' needs themselves and have to resort to pointing fingers.
Some programmers are like that, certainly, but if most developers one comes across are like that then one might have to look inwards.
Tangent: There's a Star Trek clip I wish I could find online so I'd have it on-hand to show non-technical people. It's from the 90s, in an episode of Deep Space Nine.
Worf (in Security) is having trouble dealing with Engineering, and O'Brien gives him some advice, something along the lines of "Engineers like to solve problems. Instead of telling them what to do, tell them what you need and let them figure it out.". Then later when he tries it out, they come up with a solution he wouldn't have thought of.
> Programmers should not be empowered to perform roles for which they are an ill fit. In general, programmers are detailists who speak the language of the computer
“Programmers” are not, software developers/software engineers, who are more like systems analysts than programmers in scope of job role at the full working level, though generally employed in organizations that do not also employ separate programmers, however, are and should be.
The kind of organization with wide organization/and interaction distance between users and people working on code with large numbers of over-the-wall handoffs in between is obsolete in many areas of software development because of advances in tooling, because of recognition of the quality costs imposed by that structure given the dynamics of many application domains where whiteboard analysis without real active use is not effective in getting accurate requirements, and because of the costs of that organization style which has long cycle times and high coordination overhead.
That's why I don't work with programmers in this capacity, programming is the simple part. I work with software engineers, and the best of them probably didn't even open an IDE this week yet. I don't need them to code, I need them to tell the programmers what and how to code.
I think programmer vs software engineer is one of those semantic things that might sound witty but ultimately has little utility or shared agreement. Job listings use them interchangeably. I call myself a programmer in casual conversation because it's easier and I'd feel kind of pompous saying "software engineer", even though I'm firmly on the "software engineer" side at this point.
And it sounds a little incredulous for even a senior architect to go an entire week without opening an IDE. I'd be worried I'm working under someone out of touch, too far removed from the actualization of software. Isn't that how we got the EnterpriseBeanFactoryFactory stereotype? The best team leads and architects I know still spend a lot of their time coding. One famous example is Carmack.
> And it sounds a little incredulous for even a senior architect to go an entire week without opening an IDE.
Not really. I'm at least two levels below that and about a month ago I spent 3 days straight building a document and diagrams to convince an architect that recently joined our team that one of his plans for us was bad. (Part of the reason it took so long because I had to straighten out some thoughts and figure out how to organize years of experience that has just been building in my head over time, plus come up with alternate plans that were a better way of getting to a similar-but-not-quite-the-same end goal)
I don't remember what I was doing before and after that but it wouldn't surprise me if I hadn't touched any code for over a week.
On the flipside since then I've been deep into code, doing some re-architecting of our development stack to make it easier to work with.
It was meant to be mostly a joke, I agree it's vague and I do the same as you do. Though the point stands - very senior or principal engineers/developers/architects are not there to write code.
A team lead should be hands on, I agree. But there are also technical people who operate above teams and even above departments - those probably don't code much. Most of their time is probably spent in business/strategy meetings and writing stuff in Jira and Confluence.
A principal engineer can be on the same hierarchy/influence level as a very senior manager or director, leading hundreds of people.
> Programmers should not be empowered to perform roles for which they are an ill fit. In general, programmers are detailists who speak the language of the computer; they do not have a big-picture perspective nor do they understand the problem in business terms. Their social skills are very often lacking, and they are prone to arrogance.
This seems like a problem that can be solved during hiring. These are not necessarily attributes of programmers in general, maybe just the ones you are finding.
I've worked at companies where Product and Engineering roles were separate, and information had to pass between the two in the form of docs, conversations, specs, charts and so on. I've also worked at companies where there was no dedicated product role: Engineering was responsible for the implementation, the design, the product-market fit, the customer need, everything. Honestly I think that way works better, because there is no necessary back-and-forth negotiation about priorities, features, and quality (except what goes on in the tech lead's own mind). No need to have some separate person go talk to the customer and deliver requirements to engineering on a platter. It's much more efficient. You just need to hire the engineers who are not just ticket-implementors, but who can also do the product and business work.
> Engineering was responsible for the implementation, the design, the product-market fit, the customer need, everything.
I generally agree but it's a tough sell hiring talented people as effectively one man startups with no equity.
Plus, without UBI it's not fair to remove so much organizational padding: getting paid to decorate JIRA boards may not bring any value but it keeps someone's family fed.
You’re on hackernews, not an MBA roundtable. Lot of people here have been at Apple (like me), Google (at its peak in your opinion or now) and let me queue you in on something… the leaders at Google, Apple, etc that you’re lionizing spoke about their developers the way I am. Maybe that is the gap between the typical org and the great ones
> In a high-functioning information systems organization, the programmer's job is one of simple translation from specifications into code;
That's not a job, that's a tool, and it's called a transpiler.
A "high functioning organization" fitting your description wouldn't need to have any salaried programmers after they created that simple specification-to-code compiler.
> Their social skills are very often lacking, and they are prone to arrogance
Unlike your own comment which displays these exact qualities?
Blaming enshittification, rent-seeking and blatant conflicts of interest on... SWEs with overly high opinions of their business acumen is certainly a bold claim.
Reminds me of PS/Tk, a cross-platform, cross-implementation GUI library for Scheme that worked by opening a pipe to a Tcl/Tk process and communicating with that. It actually worked fairly well, though it's sadly abandoned now. I contributed somewhat by getting it working for Gambit.
My wife still fumes that they don't make kids type two spaces after sentence-terminal punctuation anymore. And she still hasn't processed that periods at the end of sentences are, in certain contexts, considered inappropriately arrogant and to be avoided.
FWIW I think that anyone who seriously believes this needs to be told to just go fuck themselves, so if they choose to treat such style as "rude" and get offended, perhaps it's for the best after all.
Say that you have i-t
followed by apostrophe
s, now what does that mean?
You would not use "it's" in this case!
As a possessive
It's a contraction
What's a contraction?
Well, it's the shortening of a word
or group of words by omission of a
sound or letter.
It's possible to nest subprograms within subprograms in Ada. I take advantage of this ability to break a large operation into one or more smaller simpler "core" operations, and then in the main body of the procedure write some setup code followed by calls to the core operation(s).
I'm not sure why. If the point is to make the firmware read every bit of the drive, that doesn't seem like it would break any copyright law. The encrypted data is rather useless without breaking DRM, but the DRM breaking doesn't happen in hardware.
If the firmware is based on existing, proprietary drive firmware, then distributing it may run afoul of copyright law, but if all that's distributed is a patch file then I don't see the problem there either.
There are quite a few countries with exceptions in copyright law for compatibility reasons, like modifying programs to make them work on newer hardware without the original authors' consent. The reason VLC (and many other open source projects) can play DVDs is that France, where VLC is based, has laws that make it legal to distribute a DVD playback library. I don't think any Linux distros have faced legal trouble over distributing VLC, even if they are American in nature.
I'm sure the copyright lobby will have a different opinion, but I don't think it's quite as black and white without knowing where the author resides and/it what nationality they have.
The DMCA is American law, so the parent comment can only be referring to America. Obviously doesn't apply outside there.
> I don't think any Linux distros have faced legal trouble over distributing VLC, even if they are American in nature.
That's because they generally don't distribute libdvdcss, which is the illegal part.
> Many Linux distributions do not contain libdvdcss (for example, Debian, Ubuntu, Fedora and openSUSE) due to fears of running afoul of DMCA-style laws, but they often provide the tools to let the user install it themselves. For example, it used to be available in Ubuntu through Medibuntu, which is no longer available.
> The DMCA is American law (...) Obviously doesn't apply outside there.
...and when you host your code on Github or Gitlab, they will have to comply with DMCA letters. After one round of exchanging counternotices the content will have to stay down unless the alleged infringer is willing to fight the matter in a US court.
Because the purpose is to read disks protected by technological protection measures. Circumventing technological protection measures is illegal, period. That's one of the things many people don't like about the DMCA. I'd recommend to start archiving this website now.
I mean, the post is from 2019, and MakeMKV has been around much longer than that. I know this isn't always the case, but I feel like if they were going to take down MakeMKV's site, they probably would have done it by now.
Maybe to the letter of the law, but I think there’s a reason why no one seems to go after MakeMKV.
If you’re using MakeMKV, then almost by definition you have a legitimate copy of the media you’re ripping, and as such not a direct target of any kind of piracy prevention. Obviously you could then post your rip on The Pirate Bay or something, but I don’t think that MakeMKV is generally blamed for that.
I have a ton of Blu-Ray movies purchased legitimately, and I use MakeMKV to rip them and play them with Jellyfin. I don’t distribute them, I only play them in my house.
Am I technically breaking the law? Probably, DRM law is weird and confusing in the US, but I doubt that the MPAA has a huge problem with what I am doing, since I am paying them for legitimate copies of my movies.
reply