less about programming, more about programmers: just because you can code an app doesn’t mean you know jack shit about anything else… politics included
so many software engineers think they’re the only one who understands the world and that they are the one to have the final say in any discussion
i think that stems from their outrageous overpayment
When you release something, your work is not done. You have to maintain it, fix bugs, release patches, and probably the worst part, keeping it up to date.
For example, Apple decides to deprecate some API, or decides to switch cpu architecture, or for the millionth time change how app signing works, or add some new security feature that breaks your app. Now you need to make your app work properly on the new platform, switch APIs, all the fun. Or, there’s some critical vulnerability in library you used and customers are deleting your app from their computers (a lot of companies use automated scanners that check against published CVEs). It’s most fun when you learn that the new version that fixes the vulnerability completely breaks compatibility with the old one and now you have to rewrite all the code that used that library.
Also, maintaining open source projects is not fun. It’s a lot of work, in most cases unpaid, thankless, and building a community around a project is really hard.
That programming as a career means you’re going to spend writing nice, clean code 80% of the time.
It’s rather debugging code or tooling problems 50% of the time, talking to other people (whether necessary or not) about 35% of the time and the rest may be spent on actually spending time doing the thing you actually enjoy.
In my experience, you’re rather inaggerating. I’m not even 10y into my career and if I get to actually code for 2h a day, that’s already a success. Most of my time nowadays is documentation, meetings, jira, research and calls with the clients.
I think it heavily depends on the size and (management) culture of your employer. My most recent gig had me sit in way too many meetings that were way too long (1hr daily anyone?), dealing with a lot of tooling issues and touching legacy code as little as possible while still adding new features to our main product on a daily basis. Obviously “we don’t need a clean solution. We’re going to replace that codebase anyways, next year™”.
The job before that had me actually code for about 80% of the time, but writing tests is annoying and slows you down and we don’t have time for that. Odd how there was always time for fixing the regressions later.
I think it’s also a question of how you position yourself. Without noticing it, I’ve developed a kind of “will to power” in the sense that I want to shape the product we’re working on. So instead of just sitting in my corner and working on ticket after ticket, I’m actively seeking conversations with stakeholders to find out, whether it even makes sense to implement it as described in the ticket, or propose new ideas, etc.
Also, my mother taught me (by virtue of being completely untechnical) how to explain complex problems and systems in a way that non-technical people understand. So if “a developer” was needed, management often enough volunteered me.
I could pull myself mostly out of this stuff, but I’d get even more frustrated not being able to at least try to make things a bit better. So I’m putting on the headset once more.
also microservices in my experience worsen this sort of bitrot where the amount of usual duplication it involves means that even if you manage not to have poorly documented spaghetti magic that gets updated once in an eon in one service or two it still might be elsewhere and this
discourages refactoring due to the duplication
harms consistency
encourages lousiness because your stuff might mostly work on a surface level with the rest of your system because you only expose APIs and don’t need to worry that much about how your methods will be called. Which might seem convenient to use and implement in an ideal scenario, but could easily become troublesome to debug if anything goes wrong.
Programming != Computer Science. Programming is just a tool used in computer science. Computer Science is so much more and follows scientific theory and methodology.
CS is also what most problems on leetcode and the like are about. Programming is just application of CS concepts, usually wrapped in several layers of abstraction, to domain specific problems. But I’ve never seen a job posting for a computer scientist specifically, yet we all know how it often looks like.
This one might be a bit controversial, but has rung true in my general experience. Probably a lot of exceptions to these rules, but here goes:
You don’t really know a programming language until you understand a fair amount of the standard library and how packages/modules/dependencies work. Syntax is pretty easy, and any mainstream language will work just fine for solving basic leet-code style problems. But when you really spend a lot of time working with a language, you’re going to spend more time learning about common libraries and how to manage dependencies. If you’re working with a language like C++ or Java, this could also include build systems and how to use them.
Another precursor to being able to say that you know a language is that you should also be familiar with best practices (ie. how to name modules, how to write documentation, etc.) and common pitfalls (undefined behavior, etc.). This is one of the hardest parts about learning a new language in my opinion, because the language may not necessarily enforce these things, but doing them the wrong way can make your life very difficult.
Counterpoint: knowing a programming language doesn’t matter if you can solve problems. A competent programmer can pick up a new language and be productive within a few months. That is, a new language within the same paradigm - going from a imperative language to a functional language can be a drastic shift, but going from one imperative language to another is easy. If you can’t do that as a intermediate to senior developer, you’re not a competent programmer IMO.
The real skills of a good programmer are things like problem solving, debugging, understanding how to write readable and maintainable code, etc. Having deep knowledge of a specific programming language or languages is helpful and enables you to work faster, but if you’re only a skilled developer in the languages you know - if you aren’t capable of pivoting those skills to another language - you aren’t a skilled developer IMO.
Agreed overall, you will still be competent switching from one language to another, but intricacies and nuance matter a lot here. You may have enough knowledge to solve problems, but will you have enough knowledge to avoid creating new ones too? Like performance issues, or memory leaks, or other unwanted behavior? C++ is a great example here: someone that’s smart but inexperienced might just be dangerous enough to start writing classes with dumb pointers without overriding the copy constructors, and this is just a recipe for disaster.
I think it would take more than a few months to develop the kinds of experience that you need to be aware of these issues and avoid them. And while C++ is a very easy example to point out here, pretty much all languages have their share of footguns to be aware of, and it just takes time to learn them. A “deep knowledge” of a language is not just about being faster and more productive; it’s also about not creating more issues than the ones your solving.
I think the degree of footgun danger depends a lot on the language and the application. I agree that C and C++ are dangerous until you really know what you’re doing, though IMO most of the danger comes down to memory management and that’s a portable skill, once you’ve learned it. That being said, I don’t have a lot of experience with C++. C was my first language so I’m used to plain old normal boring pointers (are those “dumb pointers”?) and I’ve never understood why C++ needs 9 billion types of pointers.
Go has one particular footgun - loop range variables. Other than that, IMO high-level, garbage collected languages don’t have major footguns like that. My first job was writing a bespoke inventory system for a manufacturing company, and I wrote it in a language I’d never used before - C#. In five years the only major issue that had was due to my inexperience with SQL and had nothing to do with C#. And though I haven’t written nearly as much code, I’d say the same about Java, Ruby, Python, and JavaScript.
JS has confusing behavior, not undefined behavior. Its specs are well defined and backwards compatible to a fault, making some things unintuitive and harder to learn if you don’t learn the history of the language.
Problems with both should be avoided by learning and using standard practices. (Don’t pretend C is object oriented, always use === instead of == in js, etc…)
In complete agreement:
Result types are awesome, all future languages should be designed around them.
But programming is definitely more open to the idea of people just showing up and claiming to know stuff. You wouldn’t trust Steve to build a bridge just because he watched a bunch of engineering videos on YouTube.
Eh, I’m naturally good at it. I got shoved into the programming UIL group in school with absolutely no background in programming and tied for 3rd place.
Exact same thing happened to me. Group project needed a programmer, I was a gamer with a nice computer so I volunteered. 15 years later and I’m a software engineer at a huge company.
I call that the “nerd equivalency problem”. I think it’s the source of much (most? all?) of the problems with software that comes out of organizations that are not programming shops by nature.
“We’re not moving fast enough (or, “I have this great idea!”), hire another nerd!”
The problem also exists within individual programmers (“sure, I can do that UX/UI thingy, just let me finish building this ray-tracing thingy”), but that’s just an ordinary cognitive weakness that affects us all (thinking that being expert in one field makes one expert in all). It’s the job of proper leadership to resist that, not act as though it’s true.
That’s the difference between a programmer and a computer scientist, but even I (a computer scientist) I’m not an expert in hardware, networking, or OS level operations because that’s not my daily focus.
What’s funny about this comic now is the second one has become very attainable in the years since it was released. The concept still applies though. Some things are a lot harder than they seem on the surface.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
Myth: software engineers replicate value similar to a factory worker making the same item over and over
Truth: software engineers are closer to artists than factory workers IMO. We find and create new value, not replicate existing value
eh, more like self-important plumbers
Just making some corkscrew pipes because the existing architecture is corkscrew piping.
Or adding a single non-corkscrew pipe out of principle, which all the other corkscrew plumbers now have to maintain for 20 years
And just like artists, the vast majority aren’t very good at it.
Yes but unlike artists we have far fewer sugar daddies.
I feel this. But, in a lot of jobs you have someone forcing you to do art the way they had envisioned lol
less about programming, more about programmers: just because you can code an app doesn’t mean you know jack shit about anything else… politics included
so many software engineers think they’re the only one who understands the world and that they are the one to have the final say in any discussion
i think that stems from their outrageous overpayment
This also works the other way round:
The best programmers won’t be able to fix you clunky mess of bureaucracy by making it digital.
He’s getting downvoted but he’s right.
The hubris of a dev thinking they can solve a non tech problem with tech that they know nothing about, it’s almost unmatched.
Maybe he’s getting downvoted for his US defaultism.
Gamers demanding changes saying “it’s literally one line of code”
yeah maybe would be true if FP/FRP was widespread in gamedev… but then the industry would be moving at significantly slower pace ¯\(ツ)/¯
When you release something, your work is not done. You have to maintain it, fix bugs, release patches, and probably the worst part, keeping it up to date.
For example, Apple decides to deprecate some API, or decides to switch cpu architecture, or for the millionth time change how app signing works, or add some new security feature that breaks your app. Now you need to make your app work properly on the new platform, switch APIs, all the fun. Or, there’s some critical vulnerability in library you used and customers are deleting your app from their computers (a lot of companies use automated scanners that check against published CVEs). It’s most fun when you learn that the new version that fixes the vulnerability completely breaks compatibility with the old one and now you have to rewrite all the code that used that library.
Also, maintaining open source projects is not fun. It’s a lot of work, in most cases unpaid, thankless, and building a community around a project is really hard.
That programming as a career means you’re going to spend writing nice, clean code 80% of the time.
It’s rather debugging code or tooling problems 50% of the time, talking to other people (whether necessary or not) about 35% of the time and the rest may be spent on actually spending time doing the thing you actually enjoy.
I may be exaggerating, but only a little.
I really don’t mind any of it though.
Different strokes for folks I guess 🤷♂️
In my experience, you’re rather inaggerating. I’m not even 10y into my career and if I get to actually code for 2h a day, that’s already a success. Most of my time nowadays is documentation, meetings, jira, research and calls with the clients.
I think it heavily depends on the size and (management) culture of your employer. My most recent gig had me sit in way too many meetings that were way too long (1hr daily anyone?), dealing with a lot of tooling issues and touching legacy code as little as possible while still adding new features to our main product on a daily basis. Obviously “we don’t need a clean solution. We’re going to replace that codebase anyways, next year™”.
The job before that had me actually code for about 80% of the time, but writing tests is annoying and slows you down and we don’t have time for that. Odd how there was always time for fixing the regressions later.
I think it’s also a question of how you position yourself. Without noticing it, I’ve developed a kind of “will to power” in the sense that I want to shape the product we’re working on. So instead of just sitting in my corner and working on ticket after ticket, I’m actively seeking conversations with stakeholders to find out, whether it even makes sense to implement it as described in the ticket, or propose new ideas, etc.
Also, my mother taught me (by virtue of being completely untechnical) how to explain complex problems and systems in a way that non-technical people understand. So if “a developer” was needed, management often enough volunteered me.
I could pull myself mostly out of this stuff, but I’d get even more frustrated not being able to at least try to make things a bit better. So I’m putting on the headset once more.
also microservices in my experience worsen this sort of bitrot where the amount of usual duplication it involves means that even if you manage not to have poorly documented spaghetti magic that gets updated once in an eon in one service or two it still might be elsewhere and this
Programming != Computer Science. Programming is just a tool used in computer science. Computer Science is so much more and follows scientific theory and methodology.
CS is also what most problems on leetcode and the like are about. Programming is just application of CS concepts, usually wrapped in several layers of abstraction, to domain specific problems. But I’ve never seen a job posting for a computer scientist specifically, yet we all know how it often looks like.
Computer programming is to computer science as telescope operation is to astronomy.
A better analogy is writing vs writing.
Do you know how to hold a pen and draw letters? You can write. Do you want to write a best selling novel? Yeah that’s a different skill.
It is fun
That’s subjective. I find coding fun.
Both of your comments hurt in that way only the truth is capable of hurting.
i didn’t want to flood the thread - there’s more where that came from
This one might be a bit controversial, but has rung true in my general experience. Probably a lot of exceptions to these rules, but here goes:
You don’t really know a programming language until you understand a fair amount of the standard library and how packages/modules/dependencies work. Syntax is pretty easy, and any mainstream language will work just fine for solving basic leet-code style problems. But when you really spend a lot of time working with a language, you’re going to spend more time learning about common libraries and how to manage dependencies. If you’re working with a language like C++ or Java, this could also include build systems and how to use them.
Another precursor to being able to say that you know a language is that you should also be familiar with best practices (ie. how to name modules, how to write documentation, etc.) and common pitfalls (undefined behavior, etc.). This is one of the hardest parts about learning a new language in my opinion, because the language may not necessarily enforce these things, but doing them the wrong way can make your life very difficult.
Counterpoint: knowing a programming language doesn’t matter if you can solve problems. A competent programmer can pick up a new language and be productive within a few months. That is, a new language within the same paradigm - going from a imperative language to a functional language can be a drastic shift, but going from one imperative language to another is easy. If you can’t do that as a intermediate to senior developer, you’re not a competent programmer IMO.
The real skills of a good programmer are things like problem solving, debugging, understanding how to write readable and maintainable code, etc. Having deep knowledge of a specific programming language or languages is helpful and enables you to work faster, but if you’re only a skilled developer in the languages you know - if you aren’t capable of pivoting those skills to another language - you aren’t a skilled developer IMO.
Agreed overall, you will still be competent switching from one language to another, but intricacies and nuance matter a lot here. You may have enough knowledge to solve problems, but will you have enough knowledge to avoid creating new ones too? Like performance issues, or memory leaks, or other unwanted behavior? C++ is a great example here: someone that’s smart but inexperienced might just be dangerous enough to start writing classes with dumb pointers without overriding the copy constructors, and this is just a recipe for disaster.
I think it would take more than a few months to develop the kinds of experience that you need to be aware of these issues and avoid them. And while C++ is a very easy example to point out here, pretty much all languages have their share of footguns to be aware of, and it just takes time to learn them. A “deep knowledge” of a language is not just about being faster and more productive; it’s also about not creating more issues than the ones your solving.
I think the degree of footgun danger depends a lot on the language and the application. I agree that C and C++ are dangerous until you really know what you’re doing, though IMO most of the danger comes down to memory management and that’s a portable skill, once you’ve learned it. That being said, I don’t have a lot of experience with C++. C was my first language so I’m used to plain old normal boring pointers (are those “dumb pointers”?) and I’ve never understood why C++ needs 9 billion types of pointers.
Go has one particular footgun - loop range variables. Other than that, IMO high-level, garbage collected languages don’t have major footguns like that. My first job was writing a bespoke inventory system for a manufacturing company, and I wrote it in a language I’d never used before - C#. In five years the only major issue that had was due to my inexperience with SQL and had nothing to do with C#. And though I haven’t written nearly as much code, I’d say the same about Java, Ruby, Python, and JavaScript.
That’s what I hate about javascript, it doesn’t warm you about undefined behavior, it just throws.
I used to not really care about that, but after learning C and Rust, damm, I wish there where result types everywhere
Some small nits to fix:
C has it’s own undefined behavior.
JS has confusing behavior, not undefined behavior. Its specs are well defined and backwards compatible to a fault, making some things unintuitive and harder to learn if you don’t learn the history of the language.
Problems with both should be avoided by learning and using standard practices. (Don’t pretend C is object oriented, always use
===instead of==in js, etc…)In complete agreement:
thank you very much.
By undefined I meant the usage of undefined in the language, however you phrased it way better :)
That you can just go to a bootcamp, and be good at or naturally suited for it.
That you can go to college and get a degree, and be good at or naturally suited for it.
Well that’s true for every field.
But programming is definitely more open to the idea of people just showing up and claiming to know stuff. You wouldn’t trust Steve to build a bridge just because he watched a bunch of engineering videos on YouTube.
Eh, I’m naturally good at it. I got shoved into the programming UIL group in school with absolutely no background in programming and tied for 3rd place.
But, I really don’t enjoy doing it.
Exact same thing happened to me. Group project needed a programmer, I was a gamer with a nice computer so I volunteered. 15 years later and I’m a software engineer at a huge company.
Why are you in programming related communities if you don’t enjoy it?
I browse by all
Plus, I have to do light coding for my job (script writing)
Everyone can code.
Anyone can, but not everyone needs to
Not everyone should
And not everyone should.
I didn’t want to say that because it sounds mean, but yes, pretty much
That if you know how to code, you understand how computers work and understand really complicated math concepts.
I call that the “nerd equivalency problem”. I think it’s the source of much (most? all?) of the problems with software that comes out of organizations that are not programming shops by nature.
“We’re not moving fast enough (or, “I have this great idea!”), hire another nerd!”
The problem also exists within individual programmers (“sure, I can do that UX/UI thingy, just let me finish building this ray-tracing thingy”), but that’s just an ordinary cognitive weakness that affects us all (thinking that being expert in one field makes one expert in all). It’s the job of proper leadership to resist that, not act as though it’s true.
That’s the difference between a programmer and a computer scientist, but even I (a computer scientist) I’m not an expert in hardware, networking, or OS level operations because that’s not my daily focus.
I compare my career to the medical field. Sure there are some crossovers but lots of specialties.
Would you consult a dentist about your bowel movements?
and what you just described is the difference between a computer scientist and a computer engineer!
I don’t even remember my times tables anymore!
I know my wife sets the table at 6 o’clock
Oh, that’s easy:
Thar just because you solved a particular problem in 10min, all other problems are going to take 10min too.
Relevant XKCD: https://xkcd.com/1425
And here I was thinking of https://xkcd.com/664/
What’s funny about this comic now is the second one has become very attainable in the years since it was released. The concept still applies though. Some things are a lot harder than they seem on the surface.
Somebody spent the money on a research team and five years is why it is very attainable now.
Someone trying to write the code from scratch would still take a research team and years to replicate it from scratch.
Oh yeah, for sure
It is cool
“We’re going to clean up that code later.”
If you’re lucky this statement is actually true 5% of the time.
So roll a d20?
Critical hit! It worked on the first try and you fixed some tech debt!
Remove technical debt: Programming (Intelligence) or Programming (Wisdom), DC 15 to 20
Create technical debt: Programming (Charisma), automatic success
That coding interviews are even by the tiniest measure good indicators of how capable a candidate is for a software engineering job.
I saw a great thread on Mastodon about this: link