# Things they didn’t teach you about Software Engineering
source: https://ift.tt/sDv2ixP tags: #literature #software-engineering #insights uid: 202302202232 —
You rarely write something from scratch In university, they teach you how to write a 400-line program that solves a problem from A-Z. You have a blank canvas, and you need to show off your knowledge of some fancy algorithm to find a way to generate a maze. In the end, you have a nice solution to a straightforward problem.
It sounds like the real world, right? But it’s not. In the real world, you have a codebase of several hundred thousand lines, and you’re trying to figure out what your colleagues were smoking when they wrote this marvelous piece. You go back and forth between documentation and the person who understands the codebase more. At the end of the week, you write ten lines of code that fix some bug, and then the cycle repeats until you end up being the person people come to for an explanation of why you wrote it as you did.
Domain knowledge is more important than your coding skills I was surprised by how much easier it is to code something when you understand the underlying principles of how and, more importantly, why it needs to work.
When building a mobile banking app — you better understand how the transactions work, how money settlements work, how ledgers work, etc.
When building a Point-of-Sale system for a restaurant, you better figure out how the waitpeople operate, how the inventory is managed in gastronomy, and how the credit card authorization works. Basically, the ins-an-outs of the domain of where your software will run.
MK - This is extremely true, and an important #insights for me to have to get better at #software-engineering. I’ve noticed this with Airtable and main resilience as well. This is why Junyi has tried hard to develop domain expertise on ProxySQL - because it’s extremely important for us to be able to do our jobs well.
Writing documentation is not emphasized hard enough
This is something I can get better at going forward. 202302202224
Code is secondary. Business value is first. Nobody is going to come up to you and say, “Oh wow, great job on writing that one-liner, amazing!” what they will instead say is, “Users are happy with the feature that you wrote,” or “Your code took down the whole website” depending on how lucky you are.
Although it may sound surprising, the primary focus of a software engineer’s job is not writing code but rather creating value through the use of software that was written. Code is simply a tool to achieve this end goal. Code -> Software -> Value.
This is a fantastic #insights
I’ve spent considerable time figuring out efficient ways to deal with those incompetences without being an asshole. I think it’s a skill that should definitely be taught in universities.
One way I have found to be effective is to focus on being productive despite the other person. I try to find solutions/alternatives that may be more effective and don’t require involving the ineffective person. It’s also helpful to document everything. This can provide concrete evidence of their incompetence’s impact on the processes.
Ultimately, the best way to deal with incompetence is to be proactive and find ways to work around their limitations. This may involve:
- seeking out additional resources or support.
- finding ways to delegate tasks to more competent people. Can anyone else do what needs to be done?
- Implementing failsafe and fallback so stuff doesn’t break on your side.
- Set a 1:1 with the person to tell them they are hindering the process.
- Again — no need to be an asshole.
You work with uncertainty most of the time
Requirements gathering isn’t the easy part of programming. It’s not as fun as writing code. But it takes a considerable amount of your time as a programmer because it requires working with people, not machines — calling the agency that provides the third-party integration, and chatting with their developers to understand what’s feasible and what’s not. Sitting down with the stakeholders to tell them their ideas do not make sense and that we can do it this way and not that way.
Writing your first line of code on a task can take weeks. You figure out the requirements, then you figure out where it needs to go, then you figure out how it needs to be built, then you figure out where it might go wrong, and then you write your first lines.
Also need to get better at this. These are things that I can use for my self-review 202302202224
Assume everything has bugs
Aesthetics can’t be taught College courses teach us the basics of good code, but true aesthetics in software development can’t be taught in a classroom.
Aesthetics in software development refers to the overall look and feel of the code. It’s about how easy it is to read, understand, and maintain. Aesthetically pleasing code is clean, organized, and follows logical patterns. It’s the kind of code that makes you feel good when you look at it. Or makes you cringe when it’s terrible.
Estimations will be asked even when you don’t want to give them Managers like numbers, estimates, and asking for estimates with an idea written on a napkin. It’s just how the real world works — a business has some monetary goal, but before committing to it, it needs to understand how much it will cost.
Need to get better at estimates 202302202224