The harsh reality of good software

Hey! That's my video! Thank you for the shoutout!

Do you care how many hours someone slaved to build the desk you are using? No, and if it breaks you hate them. Its not exclusive to code.

My go to language is TypeScript on a good day and Polish on average.

As a junior I read an article about "all code is garbage". At the time I didn't pay it much attention. I went through my programmer puberty with design patterns. Clean malleable code that somehow was future proof. Now. I'm past programmer puberty. Every abstraction I have ever written has fallen short in some way or another. There is no such thing as future proof code. The best code is the one you can quickly delete and rewrite.

the manager is also the HR of my company. I can't complain about him to him. :(

I doubt very much that the person who wrote the Rollercoaster in Excel thought that they were using the right tool for the job. Its more like doing it because you can, not because you should.

My goto languages are BASIC and C/C++. There are not many other languages having GOTO nowadays.

Just because a famous framework has non-readable code, doesn’t mean readable code is bad. On a big, long term project where new people will keep coming in, it’s far more important to make code easily readable. If each function states clearly what it’s doing, reading code is similar to reading a story about what that code is doing.

I do think in the world of enterprise LOB applications that readbility is almost more important than anything. When the technical complexity is low but the domain complexity is high, code readability is important since the code is your source of truth for how a business process ACTUALLY works.

what I understand from these kind of videos is that being a good software developer it's about getting used to being a failure, which is something I excel at

What my previous team did is exactly the reason why they're now in a very bad position, they settled for "good enough, it works" and now they have a huge but fragile infrastructure they can't maintain nor change without a massive refactor

The best written code is the code that is easy to replace ... almost every good pattern or practice stems from that.

Lol, you really hit that nail on the head @24:15. I came into where I work and the repo was 10gb+ in size because devs before me were keeping data with the code.. I rebuilt everything from the ground up over years.. took care of the code base and developed a proper pipeline.. the repo is now <3 mb. On top of that, things are 1000x more clear and easy to maintain. Love your channel man!! Great stuff and it's mostly nice to know I'm not alone in some dumb experiences...

Hot take: software is hard and complex. Your job is to make it simple and build on the simplicity.

I’ve been an engineer, product manager, solutions consultant and sales manager. As soon as I stepped out of the engineering bubble I immediately got the “good enough” mindset. Once you realize that perfect code doesn’t pay the bills, and that code is only a means to an end, you get it.

I agree that experience in many ways makes software dev more difficult. I was at peak productivity/effectiveness when I was still naïve of all the best practices. It is commonly understood that 'cowboy' coding is a bad thing but in over 30 years of doing software dev and programming, it is usually the optimal strategy. Fancy tools, methodologies and paradigms are massive technical debt. Good devs know how to KISS. The vast majority of the time, good code does not mean making bulletproof code, it means making it as simple as possible without painting yourself into a corner.

The real coding wizards with 40+ years of experience have done the following.....looked at a breaking piece of code at 2am and asked "who the heck wrote this junk??" and then they saw their own name as the author at the top and remembered everything.

there's shitty code and then there's the data analyst code. that's one of the most amazing mess

I have a simple rule. code complexity should match the bussines requirement complexity. I naively started a side project that I thought was simple three years later no matter how much I refactored my code it's just complex. I learned from this that there is no such thing as a simple "real world" software. if you software is simple it has "no value" and no different from the many software projects I completed as a cs student.

I love what youre speaking about in the beginning, I am currently developing a feature at work and everything is new, I am a graduate dev trying to implement a masstransit feature and its honestly fun tbh, but productivity is slow because I am a) googling everything, b) trying to write good unit tests c) message queues are hard to debug haha. But tbh I think I am nearing the end and its awesome, feel like I have personally learned a lot, but I feel slow, too.