The problem with being a programmer...

I just broke up with a girl I've been seeing the past 2 months, that I was really into.

But in the end, it became a question of, either i'm with her, or I'm with my work.

I don't think that would happen with other professions, at least, not as easily.

I think, with other professions or projects, you tell someone "I need to work" and it's really fucking understood. "Ok, you need to work"

They understand it. If I was a lawyer.. I have a case. if I was a carpenter, I have a wall to build,
or a house. Etc. All understood things. Or physical things that can be seen.

But with programming, first of all, I work my own hours, I write software and then sell it. I do it all myself, I own my own business. I don't have normal hours like a job, but I do know my requirements, which is at LEAST 8 hours a day of solid, uninterrupted work.

If I had a "job" it would be like "gotta go to work" and that would be it.

But, because I work for myself, and because the things I build, aren't like something you physically see, nobody gets it.

My parents, as supportive as they are, will never understand how I just implemented a new design pattern and like, leveled up because of it.

They see software... buttons, and even then, when I try to explain what excites me, it's like trying to get a 3 year old interested in calculus.

How could they possibly understand the richness of what I do, how fulfilling it is
and how much I love it, when all they see
is me on a computer, clicking keys.

The same for this girl I dated.

The only place I feel where people understand,
is here.

Do you have any similar experiences to share?
Would love to hear it right now.

To all the design pattern nazis..

Don't you ever tell me that something is impossible because it violates some design pattern! Those design principles are there to make your life easier, not something you have to obey by law.
Don't get me wrong, you should where ever possible respect those best practices, because it keeps your software maintainable.
But your software should foremost solve real world problems and real world problems can be far more complex than any design pattern could address. So there are cases where you can consciously decide to disregard a best practice in order to provide value to the world.

Thanks for reading if you got this far.

Legends -> I: Interviewer

I: what is mvc architecture

Me: model.. view.. controller... and blah blah

I: mvc is not an architecture.. its a design pattern.. architecture is blah blah

I: srry U r rejected.. god bless you

Me: 😥😢

after 1hr

Me: googled 'Is mvc a design pattern or architectural pattern'

Google: shows stack overflow link

Stackoverflow: mvc is architectural pattern blah blah... accepted answer

Me: hopeless about my future

GOD BLESS THE INTERNET and SOFTWARE DEVELOPERS

While reviewing a PR from one of our newer FE devs, I ended up spending more time than I would like mulling over its composition. The work was acceptable for the most part; the code worked. The part that got me was the heavy usage of options objects.

When encountering the options object pattern (or anti-pattern, at times) in complex scenarios, I have to resist the urge to stop whatever I'm doing and convert it to the builder pattern/smack them in the head with a software design manual. As much as I would like to, code janitor is one of the least valuable activities I engage in daily, and consistently telling someone to go back to the drawing board for work that is functional, but not excellent is a great way to kill morale. Usually, I'll add a note on the PR, approve it, add a brown bag or two on that sort of thing, and make attendance mandatory for repeat slackers. Skills building and catharsis all rolled up in a tiny ball of investing in your people.

Builders make things so much cleaner; they inform users what actions are available in a context; they tend to be immutable, and when done well, provide an intuitive fluent interface for configuration that removes the guesswork. As a bonus, they're naturally compositional, so you can pass it around and accumulate data and only execute the heavy lifting bits when you need to. As a bonus, with typescript, the boilerplate is generally reduced as well, even without any code generation. And they're not just a dumping ground for whatever shit someone was too lazy to figure out how to integrate into the API neatly.

They're more work in js-land, sure; you can't annotate @builder like with Lombok, but they're generally not all that much work and friendlier to use.

My two cent: Java is fucking terrible for computer science. Why the fuck would you teach somebody such a verbose language with so many unwritten rules?

If you really want your students to learn about computer, why not C? Java has no pointer, no passed by reference, no memory management, a lots of obscure classes structure and design pattern, this shit is garbage. The student will almost never has contact with the compiler, many don't even know of existence of a compiler.

Java is so enterprise focused and just fucked up for educating purpose. And I say it as somebody who (still) uses it as main language.

If you want your students to be productive and learn about software engineering, why not Python? Things are simple in Python can can be done way easier without students becoming code monkeys (assuming they don't use for each task a whole library). I mean java takes who god damn class and an explicitly declared entry point which is btw. fucking verbose to print something into the console.

Fuck Java.

Colleagues cannot seem to grasp that allowing a user to manually update a field via an Api, that only business process should update is a bad idea.

The entire team of around 10 'software developers' cannot grasp that just because the frontend website won't set it doesn't mean its secure. I have tried many times now...

Just an example honestly... Our project follows a concrete repository pattern using no interfaces or inheritance, returning anaemic domain models (they are just poco) that then get mapped into 'view models' (its an api). The domain models exist to map to 'view models' and have no methods on them. This is in response to my comments over the last 2 years about returning database models as domain transfer objects and blindly trusting all Posts of those models being a bad idea due to virtual fields in Ef.

Every comment on a pull request triggers hours of conversation about why we should make a change vs its already done so just leave it. Even if its a 5 minute change.

After 2 years the entire team still can't grasp restful design, or what the point is.

Just a tiny selection of constant incompetence that over the years has slowly warn me down to not really caring.

I can't really understand anymore if this is normal.

Worst architecture I've seen?

The worst (working here) follow the academic pattern of trying to be perfect when the only measure of 'perfect' should be the user saying "Thank you" or one that no one knows about (the 'it just works' architectural pattern).

A senior developer with a masters degree in software engineering developed a class/object architecture for representing an Invoice in our system. Took almost 3 months to come up with ..

- Contained over 50 interfaces (IInvoice, IOrder, IProduct, etc. mostly just data bags)
- Abstract classes that implemented the interfaces
- Concrete classes that injected behavior via the abstract classes (constructors, Copy methods, converter functions, etc)
- Various data access (SQL server/WCF services) factories

During code reviews I kept saying this design was too complex and too brittle for the changes everyone knew were coming. The web team that would ultimately be using the framework had, at best, vague requirements. Because he had a masters degree, he knew best.

He was proud of nearly perfect academic design (almost 100% test code coverage, very nice class diagrams, lines and boxes, auto-generated documentation, etc), until the DBAs changed table relationships (1:1 turned into 1:M and M:M), field names, etc, and users changed business requirements (ex. concept of an invoice fee changed the total amount due calculation, which broke nearly everything).

That change caused a ripple affect that resulted in a major delay in the web site feature release.

By the time the developer fixed all the issues, the web team wrote their framework and hit the database directly (Dapper+simple DTOs) and his library was never used.

I need to vent or I'm going to fucking explode like a car filled with bombs in motherfucking Iraq...

A couple of months ago I inherited a project in development from our team leader who was the sole developer on it and he was the one who designed every single thing in it.

I was told the project is clean, follows design patterns, and over all the code is readable and easy.

Those were all fucking lies.

See throughout the period he was working on it, I saw some of the code as it was going through some pull requests. I remember asking the dev why he doesn't comment his code? His response was the most fucking condescending shit I've ever heard: "My code is self-documenting"...

Now that I have full control over the code base I realize that he over engineered the shit out of it. If you can think of a software design pattern, it is fucking there. I'm basically looking at what amounts to a personal space given to that dev to experiment with all kind of shit.

Shit is way too over engineered that I'm not only struggling to understand what the hell is going on or how the data flows from the database to the UI and in reverse, I'm now asked to finish the remaining part and release it in 8 weeks.

Everything is done in the most complicated way possible and with no benefits added at all.

Never in my career have I ever had to drag my sorry ass out of bed to work because I always woke up excited to go to work... well except for the last 2 weeks. This project is now taking a mental toll and is borderline driving me crazy.

Oh, did i tell you that since he was the only dev with no accountability whatsoever, we DO NOT EVEN KNOW WHAT IS LEFT TO BE IMPLEMENTED?

The Project Manager is clueless.. the tickets board is not a source of truth because tickets set to resolved or complete were actually not even close to complete. FUCK THIS SHIT.

For the last week I've been working on 1 single fucking task. JUST 1. The whole code base is a mine field. Everything is done in the most complicated way and it is impossible for me to do anything without either breaking shit ton of other features (Loosely coupled my ass) or getting into fights with all the fucking libraries he decided to use and abuse.

1 whole week and I can't even get the task done. Everyday I have to tell the project manager, face to face, that I'm still struggling with this or that. It's true, but i think the project manager now thinks i am incompetent or just lazy and making excuses.

Maybe I'm not smart enough to understand the what and why behind every decision he made with this code. But I'm sick to my stomach now thinking that I have to deal with this tomorrow again.

I don't know if I'll make the deadline. But I'm really worried that when this is released, I'll be the one maintaining that nightmare of a code base.

From now on, if i hear a fucking developer say their code is "self-documenting" I will shove my dick + a dragon dildo + an entire razor gaming keyboard up their ass while I shoot their fucking knees off.

oh... and there are just a couple of pages of documentation... AND THEY ARE NOT COMPLETE.

Teach students the importance of clean code/architecture and testing. Even if they dont yet understand the more complex topics such as architecture, they should understand why quality is important and that software is a craft more than a science. You cant just apply principle X and insert design pattern Y and profit++. You actually have to think and constantly improve. AND TEST.
Think I would probably also cover things like build automation and continuous delivery. These are now important things for junior devs to know about going into companies.

i had an epiphany today, in a discussion with the software architect of our new project.

i'm having the epic job to design & implement a prototype for a C++ library in a new software project and collected some inspiration in our "old" software, where i'm maintaining the module that fulfills the same functionality (i thought). i've been maintaining this module for around a year now. i analyzed the different features and stuff to consider and created a partial model of the new library.

when i showed it to the architect today, he was like "oh my god, no no no, you don't need all this functionality, this shall not be part of the new library!"

this was the moment when i realized how deeply fucked up the code base of the old module is.

imagine it like this:
you want to automate the process of making yourself a good ol' cup of coffee.
the reasonable thing would be to have

- a smart water boiler where you set parameters water temperature and amount of water to be fetched from the water supply
- a smart coffee bean grinder where you can set type of beans, amount of beans and grinding fineness
- a component where water and ground coffee are joined to brew the coffee, where parameters like duration, pressure etc. are set
- a milk tank where amount of milk, desired temperature and duration / speed of foaming can be set
- a sugar dispenser where amount of applied sugar can be set
- optionally, additional modules with spices, syrup, ice cubes, whatever for your very personal coffee experience

on requesting a coffee, you would then configure and orchestrate all components to your wishes to make you a fine cup of coffee. you can also add routines like "makeCappucchino()", "makeEspresso()", or whatever.

our software is not like this.
it is like this:
- a smart water boiler consisting of submodules that know how to cook water for e.g. "cappucchino with sugar" or for "espresso without sugar, but with milk and ice cubes"
- 5 smart bean grinders that know how to grind beans for e.g. cappucchino, espresso, latte macchiato and for 73ml of water preheated to 82°C
- a very smart sugar dispenser that knows how to add sugar to 95, 98 and 100°C coffee and to coffee made of BOTH coffee arabica AND coffee robusta beans.

etc. etc., i think you're getting the gist.

when i realized this, it was like, right in front of my eyes, this terrible pattern emerged like a foul, corrupted caleidoscope of chaos, through the whole code base of this module.
i've already known how rotten from the core this code base is, but today i've actually identified a really bad pattern that i hadn't realized before. the whole architecture is so bloated that it is hard to have an overview of the whole thing. and it would require a LOT of refactoring to repair this pattern.
but i guess it would also be infinitely satisfying because i could probably reduce the code base for 30% or something...

but unfortunately, this is never going to happen, because screw refactoring.

it's a great feeling to start this new library from scratch, tho...

I think another intriguing job asides programming is engineering (*for some*). A week has past and I've been on the hike assisting my beloved brother on his contracted engineering job while I am less occupied. The job is based on 🗼Tower analysis and It's quite risky as you'd have to climb up to 56 meters high just to take readings of antennas, and fix some other stuffs. The only thing I find intriguing about this job is his love for it, funny enough he also thinks I love the job too and I guess I'm guilty for his thoughts (*Sorry bro, I love the job for you not me*).
With my little experience so far on my *new brotherly job* I noticed the most hectic task isn't going up and down the tower taking readings but at the end of all operations, he'll have to gather the values and snapshots he took while on the tower to prepare reports on msword & excel for the other buttwags at the office (or home I guess)
then archive and sends via mail. Seeing this lengthy process I was forced to ask why he wasn't using any reporting tool like Jotforms or any other equivalent and I was willing to look up some recommendations for him, his reply was: "I'm already used to this form of reporting, its what I was trained with and what the company provided, nevertheless a friend of mine suggested something of such weeks back but I would have to pay monthly fee for its usage which is quite on the high side and I don't think I'd prefer that."
Sounds convincing but not enough, okay here is another deal: You use an android phone right? and at my office we work on system automation (*basically does not know what I do for a living probably thinks I'm a hacker the illegal one*), how about i design you an android app for you to capture the tower data and a PC software for you to auto generate the msword & excel reports, I can get this ready for you in less than 5 nights (*I've got less task on my desk, and was willing to take the timeout to prepare the solution that he needed, all I needed to hear for a kick start was an "Okay" just to be sure he wants it*) I suggested and re-assured but up to this point he still declined my offer and is willing to stick with his current reporting pattern (*Me died*).

!rant
TL;DR: Can anyone recommend or point at any resources which deal with best practices and software design for non-beginners?

I started out as a self-taught programmer 7 years ago when I was 15, now I'm computer science student at a university.
I'd consider myself pretty experienced when it comes to designing software as I already made lots of projects, from small things which can be done in a week, to a project which i worked on for more than a year. I don't have any problems with coming up with concepts for complex things. To give you an example I recently wrote a cache system for an android app I'm working on in my free time which can cache everything from REST responses to images on persistent storage combined with a memcache for even faster access to often accessed stuff all in a heavily multithreaded environment. I'd consider the system as solid. It uses a request pattern where everthing which needs to be done is represented by a CacheTask object which can be commited and all responses are packed into CacheResponse objects.

Now that you know what i mean by "non-beginner" lets get on to the problem:

In the last weeks I developed the feeling that I need to learn more. I need to learn more about designing and creating solid systems. The design phase is the most important part during development and I want to get it right for a lot bigger systems.
I already read a lot how other big systems are designed (android activity system and other things with the same scope) but I feel like I need to read something which deals with these things in a more general way.

Do you guys have any recommended readings on software design and best practices?

1. Teach DS and Algos. Not basics but advanced data structures and the ones that are recently published.
2. DBMS should show core underlying concepts of how queries are executed. Also, what data structures are used in new tech.
3. Teach linkers, compliers and things like JIT. Parsers and how languages have implemented X features.
4. Focus on concept instead of languages. My school has a grad course for R and Java. (I can get that thing from YouTube !!)
5. Focus a little on software engineering design pattern.
6. It's a crime to let a developer graduate if he doesn't know GIT or any version control. Plus, give extra credits for students contributing to open source. Tell them if they submit a PR you get good grades. If that PR gets merged bonus (straight A may be ?)
7. Teach some design pattern and how industry write code. I am taking up a talk at school to explain SOLID design pattern.

Mostly make them build software!
Make them write code!
Make them automate their homeworks!

Make them an educated and employable student.!

I have actually two, but I'll write the other one in the week.

So we had classes about software engineering. The class was interesting but the teacher wasn't. Too soft, too slow, too low, too monochord (usual french), it was boring. So we ended up not listening to him. Kinda regret this.

We got a first exam, where we were in group to develop a Test Manager for Unit Test (yep.)
We had instructions, like the note would be multiplied by the percentage of coverage of code, etc.

The thing is, we really didn't get the point of the project. Now that I think of it, it seems obvious, but it wasn't back then as it was too new. In the four people of our group, one worked real hard on it, I tried to do my best, the others too.

But like I said, I didn't get back then the point of the topic, which is to apply design pattern, unit testing, etc. It was furstating af and we ended up with a 9/20.

I got the point of the topic only for the second exam, the most classic one, on a paper sheet with questions to answer. (We were allowed only one cheatsheet, I understood the topic while doing it. Sad, huh ?)