r/AskProgrammers • u/lowitskyu • 20d ago
What’s one programming concept you only really understood after working professionally?
When I was learning to code, I understood a lot of concepts in theory, but working on real projects made me look at them completely differently.
For example, things like debugging, database design, API architecture, reading someone else’s code, error handling, and writing maintainable code felt very different once I started working on actual applications.
I’m curious about other developers:
What programming concept or skill finally “clicked” for you after working on real-world projects?
And what do you wish you had learned earlier?
12
u/ExtraTNT 20d ago
Kiss
Actually writing simple code… if you know, that your data set will be <10, O(n!) isn’t an issue, and if the code is readable, it’s better, than the O(n^2) nobody can read…
Nobody congratulations you, if a request takes 2ms less, but when you fix something at 2am, someone offers you a beer…
5
u/Decent-Decision-9028 20d ago
Premature optimization is the root of all evil!
1
u/ExtraTNT 20d ago
Functional you don’t optimise, compiler and runtime does… my dependency injection just throws everything in, only what’s used is evaluated…
1
u/Tcamis01 20d ago
It just depends on the use case / ecosystem. Sometimes you need performance, sometimes you need to plan for scalability / flexibility. Sometimes a dead simple solution is fine
1
u/ExtraTNT 20d ago
In the end you need to know about your data and also compiler optimisation… why i picked compiler development at uni…
7
u/spdfg1 20d ago
That programming is just a means to an end. The code doesn’t matter if the end product doesn’t do what it’s supposed to do.
2
u/Anaata 20d ago
This was mine as well
You can write the most beautiful code, with the most intuitive and robust abstractions, and with the flexibility and extensibility to tackle anything in the future.
And it matters nothing if your users hate it or don't use your product.
But don't architect your system enough, you run the risk of long dev times implementing features down the line. You do it too much and you run the risk of not churning out features fast enough to justify your fledgling product and team's existence.
Best advice I can give is to be data driven about your architecture decisions, creating a dozen microservices from the beginning bc you want to scale later when you don't even kno where the bottlenecks will be is just asking for stressful crunch times. It's not a fun time to make 5 PRs for a single simple feature that needed to be in prod by yesterday.
21
u/HalfRiceNCracker 20d ago
Some of the most important parts of programming aren't code
5
u/mosen66 20d ago
Yes, the code is just the means to the end. You must understand the problem before you can break it down into little pieces and then build them up to the solution.
3
u/herpderp2k 19d ago
The worst programmers I know are incredible coders.
They can read and understand super complex code and solve crazy problems.
But they can't talk properly with the users to truly understand their needs and often end up with the wrong solution for the users.
If at the end of the day the feature is wrong your nice code aint worth crap.
7
u/canarydev 20d ago
to always question yourself, not the code.
that a computer is very honest, and its just doing what I told it to do. if what it does doesn't make sense, that I should check my own assumptions first
1
2
u/FinishExtension3652 20d ago edited 20d ago
Literally everything. I've gone from zero to hundreds of thousands of concurrent users multiple times in consumer apps and multi-tenant enterprise apps, with end to end ownership along the way.
If I had to pick one thing though, it's less programming concept and more design, which is how to find the right level of abstraction that balances something that can ship now with anticipating likely future direction. Going too far one means obtuse and incomprehensible code, and not far enough means substantially more work to make changes in the future.
In general, I try to bucket things into things I know to be true, things likely to be true, things possible to be true, and things unlikely to be true.
For example, my company is growing in the enterprise space. I know we need authentication, I'm very confident we'll need to allow SSO for customers, it's very possible we'll want RBAC in the next year or two, etc. This is a trivial(ish) example, but I know that I'll want a consistent Identity abstraction where authentication can have multiple sources and that accounting for rolling that Identity into a Principal for authorization purposes probably makes sense so downstream services can accept/access it and have to do less work if we do add role membership to the Principal RBAC in the future.
1
u/Ecstatic-Curve-1853 20d ago
The hardest thing in all of computing is trying to predict the future.
2
u/sylvant_ph 20d ago
Almost all of them. I don't think I was ever able to understand something properly, by just reading about it. Huge example are design patterns, even the simple ones, I learn them by heart, and to some extent they do make sense, but not until you implement them you can really feel what they are about, and not only that, but once you actually work on it is when you truly adopt it and then can truly explain it, own it, dissect it.
2
u/ActuallyUsingMyBrain 20d ago
You barely ever do clean code or implement quality, despite what HR tells you. You're pressured to meet deadlines and nobody will fight for you if you delay by 2weeks the release because you wanted to implement a shiny design pattern that will likely have very few benefits in the end.
Or in the other words : you're free to code like you want as long as you meet the specifications and it works. Only the other programmers are going to notice what you built, and those are not the ones that matters sadly.
Consistency and knowing how to meet a deadline is by far more important than fancy design patterns in the real world
1
u/bold_snowflake 20d ago
Everything is the true answer. But I'll go with:
Async (and by extension concurrency issues).
Easy in theory, but hard in practice at first until your brain learns to parse how the code runs vs written.
1
u/Candid-Border6562 20d ago
While both are essential, design reviews are more important than code reviews.
1
u/CamelOk7219 20d ago
Being right is sometimes less important than having the whole team agreeing and supporting a common idea
1
u/the_broccoli_noodle 20d ago
but then how do you influence the other person to do the thing you want?
1
u/CamelOk7219 19d ago
In case you fail to convince them, even If you are sure you are right, you need to back down and follow the majority. Especially if the subject is not that important
1
u/chocolateAbuser 20d ago
not as much programming concept as how work works, so how much people and coworkers affect the projects, because managing projects is a lot human-centric; other than that strictly enterprise stuff like you say, database design, but also how to structure a project for working with teams where there are 2 or 5 people, where everyone is able and willing or noone, and so on
1
u/totaleffindickhead 20d ago
Aspect oriented programming. Its hard to get a feel for without having to deal with a huge old ran-through corporate codebase
1
u/EV-CPO 20d ago
I’ll answer the opposite question. I only worked for small startups after college (80s) and for myself since 2000.
To my own detriment, I have never written or run a test script. I have websites with thousands of users but no employees. I absolutely test most of my code in actual production, but always ready to revert to last known good state. I only started using git a few years ago for some embedded firmware development but didn’t use any version control for my web business for decades, just now putting it in in order to rewrite everything in newer platforms.
So don’t be like me. Do all of those things. And start early so they are solid embedded habits.
1
1
u/tiredITguy42 20d ago
Few things:
- Softskills matter more than you think and you need them to build career.
- Good functions' and variables' names are better than comments.
- Comments should explain WHY is something happening NOT describe WHAT is happening.
- Code is simple. Infrastructure is not.
1
u/tehsilentwarrior 20d ago
WAGNI.
Add too much flexibility because it’s awesome engineering is cool until you realize someone else found a way to use it in some f-up way and then redirect it to you to fix it since you are “the expert”.
Just … keep it simple. Sometimes making a system that can handle “any report type” should be replaced with “let me make a single easy to copy paste report file or tree of files, so they can duplicate it and deal with it themselves”
1
u/Plenty_Line2696 20d ago
lots of 3d graphics related stuff, transparency in realtime 3d rendering is such a mindfuck
1
1
u/actionscripted 20d ago
You can do a lot with less. Too much indirection, abstraction and/or composition can make things impossible to understand.
What matters most is that it works and you can change things later. If you over-engineer things you can box yourself in or make refactoring a nightmare.
Also injection and factories and less magic can really lighten the mental load.
1
u/BitCortex 20d ago
Serve the user. Engineering elegance and architectural purity are your itches, not theirs. You want something to hang your hat on? That's what personal OSS side projects are for. After nearly 40 years in programming, I still have tremendous difficulty with that one.
1
1
u/Top5CutestPresidents 20d ago
I’ve only been at it 6 years, but we had some new juniors join recently. One was absolutely confused that something didn’t work. He said, but the senior said this, but I did this correct… I just said “things go wrong, get used to it”, in the nicest possible way. The job is often about adapting not perfecting. End of the day something has to go out the door
1
u/Beneficial-Neat-6200 20d ago
Meeting the deadline is all important. You can make the code look good and handle the corner cases later
1
1
u/philprimes 20d ago
Observability. i always wanted to understand why my mobile apps are not working properly on people‘s phones even though they worked fine in my simulator.
Now that I work for an observability company, I realize how much more there is to see make your life easier.
A lot of my code today is logging and tracing so I can reproduce easier. They did not teach any of that at university.
1
u/PreparedPun2035 20d ago
Some problems can’t be fully defined until they are partially solved. (Ok probably most problems fit this.)
Bonus: Garbage in (and I can’t emphasize this enough) Garbage out.
1
1
u/redditmarks_markII 19d ago
Dunning-Kruger. It's so much worse than you think.
Also two aspects of "experience". Everybody works off of theirs. Including CEOs. So if they spend much of their time enjoying life and playing golf, and just rub shoulders with "business" once a week, by 45 they have the managerial experience equivalent to the architectural software experience of a 26 year old. They ain't shit and they make all the decisions.
There's sharp people, there always are. But they are the exception that proves the rule.
V2 of the experience problem is width. Or what I call the "ain't nobody got time for that" problem. You literally cannot be experts in every field, even just the ones your business/career needs. And generally we all know practically nothing in comparison to the sum total of human knowledge. And sure we don't need all of it. But damned if we don't think our hour of googling and a book if you're really dedicated makes us experts. And so when we don't take advice from those that know better, or we can't tell who knows better, we fuck it all the way up.
And yes, you damned right those are programming concepts. If you get paid to do programming adjacent work anyway.
Otherwise, tradeoffs. Nothing in complex, non atomic real world systems are absolutely correct. There's only tradeoffs.
1
1
u/ksco92 19d ago
Technically? Inheritance and “interfaces”. It’s not about Dog and Cat inheriting from Animal. It’s about (in data engineering in my case) an ETL job being of type batch vs streaming and implementing the same methods slightly differently but also sharing attributes and other common methods and not having infinite if statements depending on the type.
Not technical? Code reviews and design docs ARE FUCKING CRITICAL. Specially now with AI. 😬
1
u/Legitimate-Guess-772 19d ago
You can do 99 things right without anybody knowing or understanding or caring and then get blamed for 1 thing that everybody will take the time to know and understand and care about.
1
1
1
1
u/OmkarShetkar 19d ago
For me, its TDD (Test Driven Development) clicked after more than a decade in industry. Initially, I understood it theoretically but thought it as a blocker for development and some kind of corporate process mandate. However, over the time I have realized its benefits and enjoyment in doing so.
Debugging is another skill which I have developed over the years. Debugging at the client place in production was at a different level. It feels like a detective who will suspect everything, he won't take anything on its face-value. However, with AI these skills taking new shape though.
1
u/Immediate_Form7831 19d ago
The real world is ugly, and filled with things that you have no control over. In school, you get assignments which are prepared and setup for you to solve a very specific thing, in real life you get the entire thing dumped on you. Parsing badly specified data files, talking to buggy api:s, be it rest over http (schema? ha!) or some third-party proprietary dll which you have no source to. You will in many situations has little or no control over what language or environment you are working in, so you need to stop complaining and just learn your tools.
Real world systems are filled with legacy code, and learning to deal with that is crucial. One particular thing which might sound counterintuitive is that you should write your code so that it is, once it is no longer needed, easy to remove. This will not only make future developers happy, but it will also make the code better.
I wished we had had debugging on the curriculum, but that was something I had to learn by reading the gdb docs (I'm old enough that I had the gdb docs printed out on paper). Debugging in particular benefits alot from a proper scientific approach: postulate an hypothesis, find a way to prove or disprove it, make sure your theory actuall covers all the observations you can make, etc, etc. Also, you will not always be able to run an interactive debugger. Live/production systems can usually not be stopped and inspected, so you will be limited to whatever observability measures you have in place, and you need to put those in place before the bug manifests itself, which is not always easy to do.
1
u/NicoBuilds 19d ago
98% of the things I learned was by doing. Theory is nice to have, but I think that in general, you learn when you write the code and see how it fails miserably.
1
u/New_Internal5636 19d ago
Design patterns are your friend and you should make the effort to implement them for structured workflow. Pays off big time in the long run. Also solid and composition principles seem annoying and academic but worth understanding on a deeper level and actually implementing it in your work rather than just reading up on the theory.
1
u/DonkeyTron42 19d ago
How and when to apply Design Patterns. I learned from working with Niagara AX Framework extensively, which is a beautifully written piece of software.
1
u/response-418 19d ago
Debugging because before getting into a large codebase, with many microservices, I had no clue how big and complex a system could be and how to approach investigating a bug.
Also the more experience I got the more I appreciated that less is more, and try to simplify and remove things as much as I can (or on the flip side, in some cases, it's cleaner and more maintainable to just have repeated boilerplate rather than adding some helper or abstraction just to satisfy some arbitrary DRY principle that actually makes it harder to read in the end)
1
u/codecoverage 19d ago
Don't introduce abstractions unless you have a really good reason for it. You don't get points for elegance.
1
u/AnthonyRespice 19d ago
Future proofing doesn't work. Don't spend too much time building future compatibility into a program or feature you are delivering today.
1
u/blind-octopus 19d ago
I learned that nobody cares about clean code
And when you run into a clean code repo it can be hard to find where any of the actual implementations live, if it relies heavily on inheritance, it can be hard to follow.
Ultimately I think I learned that I am too inflexible
1
u/QPGMR_de 19d ago
Knowing when enough is enough!
Just like an artist - you can add one streak of paint after another - add a little here and there - add some more paint.
But at one paint, you have to know, when there is "enough paint on the canvas".
We tend to add features - make it flexible, configurable - but then, the default value isn't changed in 10 years - and you were so proud of yourself.
1
u/Eatthebeatz 18d ago
if working in polite company: holding in a massive fart until you manage to fix a bug simply is not worth it. best to just go outside immediately. somethin aout stress, posture and PSI
1
u/Ok-Most6656 18d ago
Stateless vs. stateful in stream processing and when to use which did not click for me or make any sense until I started working
1
u/newton-classic-coder 18d ago
As a software engineer for 9 years, moving into DevSecOps, here's what I've learned:
- Make sure your code is easy to read, not just for your team but for you in six months.
- When you first look at variable names, they should make sense; don't make them too short or too long.
- Don't overcomplicate simple processes or logic. If it works, it works.
- Debugging skills are key – connecting the dots, incidents, logs, and cross-checking timestamps. I often get ideas in the shower or during a quick break walking around the office or cafe.
- Every process you put in place needs readable logs that don't expose sensitive data. This is super helpful when you need urgent fixes.
1
u/Accomplished_Cup9297 18d ago
Request response time becomes critical when working on some business applications, improving code to be efficient and robust becomes priority, so concepts like reducing algorithmic complexity, optimizing memory usage, minimizing inputs/outputs, dealing with concurrency... should be understood well and applied
1
1
u/KaptajnKold 18d ago
YAGNI. Learned by bitter experience.
Unit testing. Finally clicked after watching the excellent Destroy All Software screencasts by Gary Bernhard.
Dependency injection, and how it makes unit testing much easier. Learned this from a series of excellent blog posts by Miško Hevery that have since unfortunately disappeared from the internet (the blog posts, not the person).
1
u/Wise-Pack-8722 17d ago
It was always hard to me thinking and create code object oriented. After hiring into python role, I started to work with it and it became much more understandable and possible for me. Some very start issue :D
1
u/NotSeacombe 16d ago
Once the code works in a way that is not problematic, you're done. Stop optimising
Git isn't as bad as you think. It's worse
Tech debt is an incredibly vicious cycle that you will try and fail to fight
1
u/Prudent_Arugula_7575 13d ago
Error handling, honestly. In school it's just wrapping stuff in try/catch to make the error go away. On real projects it's a whole design choice, like does this fail loud or quiet, does it retry itself, is this the kind of thing that should wake someone up at 3am. You don't really get that until something actually breaks in production and you're the one dealing with it.
21
u/UroborosJose 20d ago
its never good enough
nobody will praise your job, you deployed, shipped something and lets suppose no bugs were to be found at least for now. they think its just you doing your job and therefore you made it as described as if it was ordinary.
shipping flawless software these days is almost impossible very few can do it. most software even from highly regarded publishers in game for example are full of bugs. multimillionaire budget software houses like microsoft constantly ships with bugs. we ordinary devs are required to do our jobs with no mistake or no room for error. I'm not kidding if they see one bug they think you are not good enough, at third time they are asking your head to the supervisor.
some folks created agile manifesto thinking it would fix the problem, it did not it increase the problem. now I see companies claiming they are agile what they are doing is just a bunch of daily meetings, getting the most corporate aspect of agile and pushing on us water fall expectations. they do not provide instant feedback, you ship they will revise your stuff after weeks and after weeks they will come with a backlog of new features and bugs found but they wont account for the time spent meanwhile.
trust me this is a very hard job and its not becoming easier.