rant? rant!

I work for a company that develops a variety of software solutions for companies of varying sizes. The company has three people in charge, and small teams that each worked on a certain project. 9 months ago I joined the company as a junior developer, and coincidentally, we also started working on our biggest project so far - an online platform for buying groceries from a variety of vendors/merchants and having them be delivered to your doorstep on the same day (hadn't been done to this scale in Estonia yet). One of the people from management joined the team working on that. The company that ordered this is coincidentally being run by one of the richest men in Estonia. The platform included both the actual website for customers to use, a logistics system for routing between the merchants, the warehouse, and the customers, as well as a bunch of mobile apps for the couriers, warehouse personnel, etc. It was built on Node.js with Hapi (for the backend stuff), Angular 2 (for all the UIs, including the apps which are run through a WebView wrapper), and PostgreSQL (for the database). The deadline for the MVP we (read: the management) gave them, but we finished it in about 7 months in a team of five.

The hours were insane, from 10 AM to 10 PM if lucky. When we weren't lucky (which was half of the time, if not more), we had to work until anywhere from 12 PM to 3 AM, sometimes even the whole night. The weekends weren't any better, for the majority of the time we had to put in even more extra hours on the weekends. Luckily, we were paid extra for them, but the salary was no way near fair (the majority of the team earned about 1000€/mo after taxes in a country where junior developers usually earn 1500€/month). Also because of the short deadline given to us, we skipped all the important parts like writing tests, doing CI, code reviews, feature branching/PR's, etc. I tried pushing the team and the management to at least write tests and make feature branches/PRs, but the management always told me that there wasn't enough time to coordinate and work on all that, that we'll do that after launching the MVP, etc. We basically just wrote features, tested them by hand, and pushed into the "test" branch which would later get tested and merged into master.

During development, one of the other juniors managed to write the worst kind of Angular code you could imagine - enormous amounts of duplication, no reusable components (every view contained the everything used in the view, so popups and other parts that should logically be reusable were in every view separately), fuck - even the HTML was broken (the most memorable for me were the "table > tr > div > td" ones, but that's barely scratching the surface). He left a few months into the project, and we had to build upon his shit, ever so slightly trying to fix the shit he produced. This could have definitely been avoided if we did code reviews.

A month after launching the MVP for internal testing, the guy working on the logistics system had burned out and left the company (he's earning more than twice the salary he got here, happy for him, he is a great coder and an even better team player). This could have been avoided if this project had been planned better, but I can't really blame them, since it was the first project they had at this scale (even though they had given longer deadlines for projects way smaller than this).

After we finished and launched the MVP, the second guy from management joined, because he saw we needed extra help. Again I tried to push us into investing the time to write tests for the system (because at this point we had created an unstable cluster fuck of a codebase), but again to no avail. The same "no time, just test it manually for now, we'll do that later when we have time" bullshit from management.

Now, a few weeks ago, the third guy from management joined. He saw what a disaster our whole project was. Him joining was simply a blessing from the skies. He started off by writing migrations using sequelize. I talked to him about writing tests and everything, and he actually listened. He told me that I'm gonna be the one writing them, and also talked to the rest of management about it. I was overjoyed. I could actually hear the bitterness in the voices of the rest of management when they told me how to write the tests, what to test, etc. But I didn't give a flying rat's ass, I was hapi.

I was told to start off by writing a smoke test for the whole client flow using Puppeteer. I got even happier, since I was finally able to again learn new things (this stopped at about 4 or 5 months into the project).

I'm using jest as the framework and started writing the tests in TypeScript. Later I found a library called jest-extended, but it didn't have type defs, so I decided to write them and, for the first time in my life, contribute to the open source community.

*team convo*

Dev: We will create another branch for the changes and merge them when required.

Director: Can we not do the changes in the current branch and comment them out until required? I think that’s cleaner and not confusing in my opinion.

Beautiful mf!

Bro every time this guy wants to create a PR, rather than branching off another branch and raising a PR to get it merged back in, this dude creates a fork and then makes a PR to merge the fork back in.

Holy. Fuck. Please don’t do this. It makes checking out your “branch” a massive pain in the ass. Plus, it’s totally unnecessary, and I can’t even check it out to begin with because your forked repo is fucking private you stooge. If we were in completely different orgs or doing open source I’d understand a fork. Not if you’re sitting right fucking next to me!!!!!111

Today on "How the Fuck is Python a Real Language?": Lambda functions and other dumb Python syntax.

Lambda functions are generally passed as callbacks, e.g. "myFunc(a, b, lambda c, d: c + d)". Note that the comma between c and d is somehow on a completely different level than the comma between a and b, even though they're both within the same brackets, because instead of using something like, say, universally agreed-upon grouping symbols to visually group the lambda function arguments together, Python groups them using a reserved keyword on one end, and two little dots on the other end. Like yeah, that's easy to notice among 10 other variable and argument names. But Python couldn't really do any better, because "myFunc(a, b, (c, d): c + d)" would be even less readable and prone to typos given how fucked up Python's use of brackets already is.

And while I'm on the topic of dumb Python syntax, let's look at the switch, um, match statements. For a long time, people behind Python argued that a bunch of elif statements with the same fucking conditions (e.g. x == 1, x == 2, x == 3, ...) are more readable than a standard switch statement, but then in Python 3.10 (released only 1 year ago), they finally came to their senses and added match and case keywords to implement pattern matching. Except they managed to fuck up yet again; instead of a normal "default:" statement, the default statement is denoted by "case _:". Because somehow, everywhere else in the code _ behaves as a normal variable name, but in match statement it instead means "ignore the value in this place". For example, "match myVar:" and "case [first, *rest]:" will behave exactly like "[first, *rest] = myVar" as long as myVar is a list with one or more elements, but "case [_, *rest]:" won't assign the first element from the list to anything, even though "[_, *rest] = myVar" will assign it to _. Because fuck consistency, that's why.

And why the fuck is there no fallthrough? Wouldn't it make perfect sense to write

case ('rgb', r, g, b):
case ('argb', _, r, g, b):
case ('rgba', r, g, b, _):
case ('bgr', b, g, r):
case ('abgr', _, b, g, r):
case ('bgra', b, g, r, _):

and then, you know, handle r, g, and b values in the same fucking block of code? Pretty sure that would be more readable than having to write "handeRGB(r, g, b)" 6 fucking times depending on the input format. Oh, and never mind that Python already has a "break" keyword.

Speaking of the "break" keyword, if you try to use it outside of a loop, you get an error "'break' outside loop". However, there's also the "continue" keyword, and if you try to use it outside of a loop, you get an error "'continue' not properly in loop". Why the fuck are there two completely different error messages for that? Does it mean there exists some weird improper syntax to use "continue" inside of a loop? Or is it just another inconsistent Python bullshit where until Python 3.8 you couldn't use "continue" inside the "finally:" block (but you could always use "break", even though it does essentially the same thing, just branching to a different point).

i was hired to join a team of old devs (40+) in an unnamed European country "yay goodbye 3rd world it's time to enjoy the quality of life" assist with enhancing already existing software and creating new solutions.
prior to my arrival most things were slow and super buggy, looking at the code base it shouldn't be a surprise, amateur hour everyone, logic implemented that is not needed, comment driven development, last time code review was done back in 1996. lots of anti patterns.
i swear there is a for loop that does nothing but it loops through a 100+ elements list, trunk based development with tfs since git is "not really needed"
test projects are not there.
>enter me an educated fool, with genuine passion for the craft and somehow a decent amount of knowledge.
>spent the last year fixing stuff educating people on principles and qualities.
> countless hours of training and explaining. team is showing cooperation, a new requirement comes in to develop with react.
> tear my ass creating reusable shit and self explanatory code with proper naming etc using git with feature branching, monday is first deployment day.
> today a colleague was working on an item submit a pull request and self approve it
> look at the code..... WTF the dumb fuck copied and pasted the whole code from different kendo components but somehow managed to refractor the name to test component, commented out all the code that he didn't use did the api call directly from the component, has 2 useeffects that depends on the a fucking text box changes for no reason, no redux implementation, the acceptance criteria is not achieved, and it doesn't work it just look right.
> first world country shit cannot scold, cannot complain, lead by example.
>asked him why you did this, the response was yeah probably i shouldn't have done that, i really didn't understand anything in the training but didn't want to waste time!!!!
> rest of the team created a different styled disaster with different flavors they don't even name their shit the same way.

fellow developers I'm stuck in a spaceship with a bunch of imposters, seriously i never cried in my entire life now I'm teary and on the verge of a break down.
talk with management "improving needs time" and offers me to join a yoga session to release the stress as if reaching nirvana would deliver shit on monday.
i really don't know what do is this a rant, is this a cry for help, I'm not sure, any advice is welcomed.

(Warning: This rant includes nonsense, nightposting, unstructured thoughts, a dissenting opinion, and a purposeless, stupid joke in the beginning. Reader discretion is advised.)

honestly the whole "ARM solves every x86 problem!" thing doesn't seem to work out in my head:

- Not all ARM chips are the same, nor are they perfectly compatible with each other. This could lead to issues for consumers, for developers or both. There are toolchains that work with almost all of them... though endianness is still an issue, and you KNOW there's not gonna be an enforced standard. (These toolchains also don't do the best job on optimization.)

- ARM has a lot of interesting features. Not a lot of them have been rigorously checked for security, as they aren't as common as x86 CPUs. That's a nightmare on its own.

- ARM or Thumb? I can already see some large company is going to INSIST AND ENFORCE everything used internally to 100% be a specific mode for some bullshit reason. That's already not fun on a higher level, i.e. what software can be used for dev work, etc.

- Backwards compatibility. Most companies either over-embrace change and nothing is guaranteed to work at any given time, or become so set in their ways they're still pulling Amigas and 386 machines out of their teeth to this day. The latter seems to be a larger portion of companies from what I see when people have issues working with said company, so x86 carryover is going to be required that is both relatively flawless AND fairly fast, which isn't really doable.

- The awkward adjustment period. Dear fuck, if you thought early UEFI and GPT implementations were rough, how do you think changing the hardware model will go? We don't even have a standard for the new model yet! What will we keep? What will we replace? What ARM version will we use? All the hardware we use is so dependent on knowing exactly what other hardware will do that changing out the processor has a high likelihood of not being enough.

I'm just waiting for another clusterfuck of multiple non-standard branching sets of PCs to happen over this. I know it has a decent chance of happening, we can't follow standards very well even now, and it's been 30+ years since they were widely accepted.

I'm writing all the dev things I know in a docs site as a means to be hireable should I need to switch jobs.

I'm not gonna go too deep on how I'm doing it. One style I'm enjoying is making every article take only one page long, and if they take longer, maybe consider breaking it into another article.
Fuck long articles. Yes, that's a bit autistic.

But I will describe the challenges I'm finding (which are quite many) in further detail.

One of them is that words can be ambiguous. Production can mean the production environment but it can also mean production in plain english.
And there are tons of cases like this.

Because of this, I felt a lot of confusion in my beginner days. So it my objective to write this as to prevent as much confusion as possible.

Granted, I don't want to write "development for dummies". Software is complex. But because it's complex on its own, I don't want to add complexity to the learning process through obscure language usage.

"Fine", I say, "I'll disambiguate". But this means I find myself branching out very often into fundamental or commonly used software terms like "framework", "model", "scaffold", "algorithm", "viewport", "breakpoint", etc.

Another challenge is reaching good levels of completitude.
This means I have to explain that obscure CLI flag I never used in my life.

If I don't do this, then what makes my docs different than these superficial dev.to or medium posts? Nothing.
But trying to explain EVERYTHING about a software can generate a lot of frustration: I never finish.

It also makes me wonder "do I even know shit?". I think some amount of insecurity is healthy and pushes myself forward.
But at some point it's kind of making me feel like shit. Maybe I just need to keep learning.

My work product: Or why I learned to get twitchy around Java...

I maintain a Java based test system, that tests a raster image processor. The client is a Java swing project that contains CORBA bindings to the internal API of the raster image processor. It also has custom written UI elements and duplicated functionality that became available in later versions of Java, but because some of the third party tools we use don't work with later versions of Java for some reason, it's not possible to upgrade Java to gain things as simple as recursive directory deletion, yes the version of Java we have to use does not support something as simple as that and custom code had to be written to support it.

Because of the requirement to build the API bindings along with the client the whole application must be built with the raster image processor build chain, which is a heavily customised jam build system. So an ant task calls out to execute a jam task and jam does about 90% of the heavy lifting.

In addition to the Java code there's code for interpreting PostScript files, as these can be used to alter the behaviour of the raster image processor during testing.

As if that weren't enough, there's a beanshell interface to allow users to script the test system, but none of the users know Java well enough to feel confident writing interpreted Java scripts (and that's too close to JavaScript for my comfort). I once tried swapping this out for the Rhino JavaScript interpreter and got all the verbal support in the world but no developer time to design an API that'd work for all the departments.

The server isn't much better though. It's a tomcat based application that was written by someone who had never built a tomcat application before, or any web application for that matter and uses raw SQL strings instead of an orm, it doesn't use MVC in any way, and insane amount of functionality is dumped into the jsp files.

It too interacts with a raster image processor to create difference masks of the output, running PostScript as needed. It spawns off multiple threads and can spend days processing hundreds of gigabytes of image output (depending on the size of the tests).

We're stuck on Tomcat seven because we can't upgrade beyond Java 6, which brings a whole manner of security issues, but that eager little Java updated will break the tool chain if it gets its way.

Between these two components we have the Java RMI server (sometimes) working to help generate image data on the client side before all images are pulled across a UNC network path onto the server that processes test jobs (in PDF format), by reading into the xref table of said PDF, finding the embedded image data (for our server consumed test files are just flate encoded TIFF files wrapped around just enough PDF to make them valid) and uses a tool to create a difference mask of two images.

This tool is very error prone, it can't difference images of different sizes, colour spaces, orientations or pixel depths, but it's the best we have.

The tool is installed in both the client and server if the client can generate images it'll query from the server which ones it needs to and if it can't the server will use the tool itself.

Our shells have custom profiles for linking to a whole manner of third party tools and libraries, including a link to visual studio 2005 (more indirectly related build dependencies), the whole profile has to ensure that absolutely no operating system pollution gets into the shell, most of our apps are installed in our home directories and we have to ensure our paths are correct for every single application we add.

And... Fucking and!

Most of the tools are stored as source bundles in a version control system... Not got or mercurial, not perforce or svn, not even CVS... They use a custom built version control system that is built on top of RCS, it keeps a central database of locked files (using soft and hard locks along with write protecting the files in the file system) to ensure users can't get merge conflicts by preventing other users from writing to the files at all.

Branching is heavy weight and can take the best part of a day to create a new branch and populate the history.

Gathering the tools alone to build the Dev environment to build my project takes the best part of a week.

What should be a joy come hardware refresh year becomes a curse ("Well fuck, now I loose a week spending it setting up the Dev environment on ANOTHER machine").

Needless to say, I enjoy NOT working with Java. A lot of this isn't Javas fault, but there's a lot of things that Java (specifically the Java 6 version we're stuck on) does not make easy.

This is why I prefer to build my web apps in python or node, hell, I'd even take Lua... Just... Compiling web pages into executable Java classes, why? I mean I understand the implementation of how this happens, but why did my predecessor have to choose this? Why?