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
Follow the wormhole through a path of communities [email protected]
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.
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.
"We're going to clean up that code later."
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.
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
That if you know how to code, you understand how computers work and understand really complicated math concepts.
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?
"Programming is just writing code"
Programming is, first and foremost, understanding what the fuck you want/need the computer to do. That means that some programmers (mostly analysts) may understand workflows and processes better than the people whose job depends on their knowledge of said things.
People don't realize that as you get better at programming, the amount of code you write goes down. At least in my experience, my work day has shifted to 80% thinking about what I'm going to write and then about 20% actually writing it.
That a "working" prototype with no tests is just as good as a carefully-designed and well-tested feature. I see this happen so often that a coder puts a prototype in front of a product manager or exec and they are like, "this is exactly what we need, now! Ship that!" And then misery ensues for all of the engineers that need to maintain this piece of garbage. As managers pressure the engineers to build new features on top, they inevitably break fundamental parts of it, and without a confident leader to demand that tech debt is paid off, that product will consume the souls of many desperate coders.
In contrast, if you do it right the first time, there will be significant parts of code that never need to change, and the parts that do need to change will be much easier, because it will be obvious if it breaks the tests.
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
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.
This one's a hot take, but: That Python is easy.
I've had to work with it in three projects in the past five years and I consider it one of the hardest programming languages, for anything but very short scripts.
You don't get proper compiler assistance, unless you have 100% test coverage. You don't get a helpful text editor. You don't usually get helpful type hints in libraries you use, so you have to genuinely just study the documentation and/or code. You get tons of quirky behavior in the stdlib, build tools, async stack, imports. You get breaking changes in minor versions of the language.
I find writing code in Python extremely mentally taxing, because you just get so little assistance, that you have to think of everything yourself.
Dynamically typed languages all suffer that fate. There's a reason Typescript literally has that feature in its name.
What does help though is type hinting. You "just" have to enforce it and its fallout in your entire codebase.
Yeah, we invested a lot of time into type hinting and checking, but mypy would never exit without warnings and errors, because many libraries we were using had no type hints.
It was also just exhausting/cumbersome, having to write type hints everywhere, as there's no type inference.
But yeah, we always joked that someone should create TypeScript for Python – Typhon.
I think Python is easy to learn but difficult to get past the basics. I'm also not convinced that getting past the basics is even worth it in three long run. I say this as a person who has used all Python at work for roughly 70 percent of the last 15 years. My current position is moving to Rust and my last 2 positions were moving to Go. Everybody was happier.
Requiring a candidate to know a specific programming language is stupid. Nearly all of the commonly used languages in industry are similar.
It's maybe more valuable to require knowledge in a specific framework, where knowledge is less transferrable between popular frameworks. Nonetheless, I personally rather hire an engineer that solves problems and learns flexibly rather than one that happens to know the right tech.
I've got a lot of these.
Programming is not doing leetcode problems all day long. Those problems can be a good brain exercise or a good prep for a [misguided] technical interview but in a real programming job you have next to no chance of running into problems like those. Even if you do, you're an idiot if you spend hours toiling away at a problem that somebody else already solved much more efficiently than you will. Your boss doesn't give a crap if you pulled all of the code straight from your brain.
Programmers are not hackers. The reverse might be true but hacking is about finding problems (and exploiting them) while programming is about fixing problems.
A programmer can do anything that involves code. Maybe not quite this succinct but I think most will assume you can write a mobile app or a website just because you say you can code. Websites, games, apps, and so on are written in code but they all involve different technologies, toolsets, and standards. I'm sure I could fumble my way through any kind of software but don't expect it done quickly if it's not my area of expertise.
Programming != Computer Science. Programming is just a tool used in computer science. Computer Science is so much more and follows scientific theory and methodology.
Computer programming is to computer science as telescope operation is to astronomy.
If I can code doesn’t mean I know how to do X thing on your stupid phone
Technical Leads are not rational beings and lots of software is developed from an emotional stand point.
Engineering is trade offs, every technical decision you make has a pro/con.
What you should do is write out the core requirements/constraints.Then you weigh the choices to select the option that best meets it.
What actually happens is someone really likes X framework, Y programming language or Z methodology and so decides the solution and then looks for reasons to justify it.
Currently the obvious tell is if they pitch Rust. I am not saying Rust is bad, but you'll notice they will extoll the memory safety or performance and forget about the actual requirements of the project.
Currently the obvious tell is if they pitch Rust
I would amend that to "if they pitch any language".
The best language is almost universally "whatever we already use" or for new projects "whatever the team is most familiar with". It should occasionally be reconsidered, and definitely try out new languages, but actually switching to the new language after trying it out? That should be very very rare.
Honestly? The people who say "learn to code" as the solution to getting a better job. Only some people can do this.
Also the idea that tech "just works". Have had freshly-minted CS/info types suddenly realize why the phrase "back away slowly" exists.
No programming language, development philosophy, or technology can save you from projects and business lacking clarity. Your ability to communicate and be understood is as/perhaps more important than the quality of your ideas. Consistency is better than perfection.
The misconception that we’re the person to go to to fix your printer…
..I mean we probably can fix it, but it’s a waste of our time…
Some programmers are software engineers. They solve problems, sometimes problems with great ambiguity or non-straightforward solutions.
And some programmers are... code technicians? They understand and write code, but their job seldom involves problem solving. Often times, they're asked to code an already solved problem, or mostly solved.
This is not a diss. I was in the second camp for a while. But it hurts your career to stay in that. So be careful.
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.
You NEED to be good be in math to program.
Whilest for some highly specialist fields you definitly do, but for a lot of jobs things don't get more complex than calculating averages.
OTOH, you need to be good at the same kinds of reasoning that leads one to be good at math. Not knowing much math isn't a problem, but not being able to learn math is probably a dealbreaker.
I'm bad at math and struggled heavily through calc 2 and barely passed with a D+ but had little issue with data structures and algorithms (except when the algorithms were written in math notation, but still got through it after being explained in a logical set of steps instead).
Myth: code can be ugly as long as it works, don't spend company time on making it look good or on minor optimizations.
The truth is that you can tell when effort has been put into a job. Even if it just works, the lack of discipline means that in the end it will be difficult to maintain and probably will fail in unexpected situations.
Every language has its conventions, but if I spot more than a line of separation between blocks of code, that is a common telltale sign of noob. Run from that shit.
People think computer as magic. That would be nice to make people understand that it's not. That's pretty much a dumb machine where we put our intelligence to work.
that doing more work, takes more time.
Gamers are especially guilty of this.
"that 2013 game runs at a smooth 60 fps. This medern game running at quadruple the resolution with raytracing sometimes dips to 58 fps on the same hardware. Devs must be lazy, they just need to add OPTIMIZATION to the game
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
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.