!rant

After over 20 years as a Software Engineer, Architect, and Manager, I want to pass along some unsolicited advice to junior developers either because I grew through it, or I've had to deal with developers who behaved poorly:

1) Your ego will hurt you FAR more than your junior coding skills. Nobody expects you to be the best early in your career, so don't act like you are.

2) Working independently is a must. It's okay to ask questions, but ask sparingly. Remember, mid and senior level guys need to focus just as much as you do, so before interrupting them, exhaust your resources (Google, Stack Overflow, books, etc..)

3) Working code != good code. You are an author. Write your code so that it can be read. Accept criticism that may seem trivial such as renaming a variable or method. If someone is suggesting it, it's because they didn't know what it did without further investigation.

4) Ask for peer reviews and LISTEN to the critique. Even after 20+ years, I send my code to more junior developers and often get good corrections sent back. (remember the ego thing from tip #1?) Even if they have no critiques for me, sometimes they will see a technique I used and learn from that. Peer reviews are win-win-win.

5) When in doubt, do NOT BS your way out. Refer to someone who knows, or offer to get back to them. Often times, persons other than engineers will take what you said as gospel. If that later turns out to be wrong, a bunch of people will have to get involved to clean up the expectations.

6) Slow down in order to speed up. Always start a task by thinking about the very high level use cases, then slowly work through your logic to achieve that. Rushing to complete, even for senior engineers, usually means less-than-ideal code that somebody will have to maintain.

7) Write documentation, always! Even if your company doesn't take documentation seriously, other engineers will remember how well documented your code is, and they will appreciate you for it/think of you next time that sweet job opens up.

8) Good code is important, but good impressions are better. I have code that is the most embarrassing crap ever still in production to this day. People don't think of me as "that shitty developer who wrote that ugly ass code that one time a decade ago," They think of me as "that developer who was fun to work with and busted his ass." Because of that, I've never been unemployed for more than a day. It's critical to have a good network and good references.

9) Don't shy away from the unknown. It's easy to hope somebody else picks up that task that you don't understand, but you wont learn it if they do. The daunting, unknown tasks are the most rewarding to complete (and trust me, other devs will notice.)

10) Learning is up to you. I can't tell you the number of engineers I passed on hiring because their answer to what they know about PHP7 was: "Nothing. I haven't learned it yet because my current company is still using PHP5." This is YOUR craft. It's not up to your employer to keep you relevant in the job market, it's up to YOU. You don't always need to be a pro at the latest and greatest, but at least read the changelog. Stay abreast of current technology, security threats, etc...

These are just a few quick tips from my experience. Others may chime in with theirs, and some may dispute mine. I wish you all fruitful careers!

I think the weekly rants just exist because @dfox & @trogus got banned from stackoverflow and they still have questions.

When it comes to learning cutting edge tech... Go build already!

I found Rust intimidating.

I read the first few pages of the official book, got bored, gave up.

Few months later, decided to write a "simple" tool for generating pleasing Jetbrains IDE color schemes using Rust. I half-finished it by continuously looking up stuff, then got stuck at some ungoogleable compiler error.

Few months later I needed to build a microservice for work, and against better judgement gave Rust a try in the weekend. Ended up building an unrelated library instead, uploaded my first package to crates.io.

Got some people screaming at me that my Rust code sucked. Screamed back at them. After lots of screaming, I got some helpful PRs.

Eventually ended up building many services for work in Rust after all. With those services performing well under high load and having very few bugs, coworkers got interested. Started hiring Rust engineers, and educating interested PHP/JS devs.

Now I professionally write Rust code almost full-time.

Moral of the story:

Fuck books, use them for reference. Fuck Udemy (etc), unless you just want to 2x through it while pooping.

Learning is something you do by building a project, failing, building something else, falling again, building some more, sharing what you've made, fighting about what you've built with some entitled toxic nerds, abandoning half your projects and starting twelve new ones.

Reading code is better than reading documentation.

Listening to users of your library/product teaches you more than listening to keynote speakers at conferences.

Don't worry about failures, you don't need to deliver a working product for it to be a valuable experience.

Oh, and trying to teach OTHERS is an excellent method to discover gaps in your knowledge.

Just get your fucking hands dirty!

I'm drunk and I'll probably regret this, but here's a drunken rank of things I've learned as an engineer for the past 10 years.

The best way I've advanced my career is by changing companies.

Technology stacks don't really matter because there are like 15 basic patterns of software engineering in my field that apply. I work in data so it's not going to be the same as webdev or embedded. But all fields have about 10-20 core principles and the tech stack is just trying to make those things easier, so don't fret overit.

There's a reason why people recommend job hunting. If I'm unsatisfied at a job, it's probably time to move on.

I've made some good, lifelong friends at companies I've worked with. I don't need to make that a requirement of every place I work. I've been perfectly happy working at places where I didn't form friendships with my coworkers and I've been unhappy at places where I made some great friends.

I've learned to be honest with my manager. Not too honest, but honest enough where I can be authentic at work. What's the worse that can happen? He fire me? I'll just pick up a new job in 2 weeks.

If I'm awaken at 2am from being on-call for more than once per quarter, then something is seriously wrong and I will either fix it or quit.

pour another glass

Qualities of a good manager share a lot of qualities of a good engineer.

When I first started, I was enamored with technology and programming and computer science. I'm over it.

Good code is code that can be understood by a junior engineer. Great code can be understood by a first year CS freshman. The best code is no code at all.

The most underrated skill to learn as an engineer is how to document. Fuck, someone please teach me how to write good documentation. Seriously, if there's any recommendations, I'd seriously pay for a course (like probably a lot of money, maybe 1k for a course if it guaranteed that I could write good docs.)

Related to above, writing good proposals for changes is a great skill.

Almost every holy war out there (vim vs emacs, mac vs linux, whatever) doesn't matter... except one. See below.

The older I get, the more I appreciate dynamic languages. Fuck, I said it. Fight me.

If I ever find myself thinking I'm the smartest person in the room, it's time to leave.

I don't know why full stack webdevs are paid so poorly. No really, they should be paid like half a mil a year just base salary. Fuck they have to understand both front end AND back end AND how different browsers work AND networking AND databases AND caching AND differences between web and mobile AND omg what the fuck there's another framework out there that companies want to use? Seriously, why are webdevs paid so little.

We should hire more interns, they're awesome. Those energetic little fucks with their ideas. Even better when they can question or criticize something. I love interns.

sip

Don't meet your heroes. I paid 5k to take a course by one of my heroes. He's a brilliant man, but at the end of it I realized that he's making it up as he goes along like the rest of us.

Tech stack matters. OK I just said tech stack doesn't matter, but hear me out. If you hear Python dev vs C++ dev, you think very different things, right? That's because certain tools are really good at certain jobs. If you're not sure what you want to do, just do Java. It's a shitty programming language that's good at almost everything.

The greatest programming language ever is lisp. I should learn lisp.

For beginners, the most lucrative programming language to learn is SQL. Fuck all other languages. If you know SQL and nothing else, you can make bank. Payroll specialtist? Maybe 50k. Payroll specialist who knows SQL? 90k. Average joe with organizational skills at big corp? $40k. Average joe with organization skills AND sql? Call yourself a PM and earn $150k.

Tests are important but TDD is a damn cult.

Cushy government jobs are not what they are cracked up to be, at least for early to mid-career engineers. Sure, $120k + bennies + pension sound great, but you'll be selling your soul to work on esoteric proprietary technology. Much respect to government workers but seriously there's a reason why the median age for engineers at those places is 50+. Advice does not apply to government contractors.

Third party recruiters are leeches. However, if you find a good one, seriously develop a good relationship with them. They can help bootstrap your career. How do you know if you have a good one? If they've been a third party recruiter for more than 3 years, they're probably bad. The good ones typically become recruiters are large companies.

Options are worthless or can make you a millionaire. They're probably worthless unless the headcount of engineering is more than 100. Then maybe they are worth something within this decade.

Work from home is the tits. But lack of whiteboarding sucks.

Uh, I gotta do Task #1337. It better is a good one!

*reads the title*

"Write technical documentation for... "

... D'oh!

writing library code is hard.

there are sooo many details that go into writing good libraries:

designing intuitive and powerful apis
deciding good api option defaults, disallowing or warning for illegal operations

knowing when to throw, knowing when to warn/log
handling edge cases
having good code coverage with tests that doesn't suck shit, while ensuring thry don't take a hundred years to run

making the code easy to read, to maintain, robust
and also not vulnerable, which is probably the most overlooked quality.

"too many classes, too little classes"

the functions do too much it's hard to follow them
or the functions are so well abstracted, that every function has 1 line of code, resulting in code that is even harder to understand or debug (have fun drowning in those immense stack traces)

don't forget to be disciplined about the documentation.

most of these things are
deeply affected by the ecosystem, the tools of the language you're writing this in:

like 5 years ago I hated coding in nodejs, because I didn't know about linters, and now we have tools like eslint or babel, so it's more passable now

but now dealing with webpack/babel configs and plugins can literally obliterate your asshole.

some languages don't even have a stable line by line debugger (hard pass for me)

then there's also the several phases of the project:

you first conceive the idea, the api, and try to implement it, write some md's of usage examples.

as you do that, you iterate on the api, you notice that it could better, so you redesign it. once, twice, thrice.

so at that point you're spending days, weeks on this side project, and your boss is like "what the fuck are you doing right now?"

then, you reach fuckinnnnng 0.1.0, with a "frozen" api, put it on github with a shitton of badges like the badge whore you are.

then you drop it on forums, and slack communities and irc, and what do you get?

half of the community wants to ban you for doing self promotion

the other half thinks either
a) your library api is shitty
b) has no real need for it
c) "why reinvent the wheel bruh"

that's one scenario,

the other scenario is the project starts to get traction.

people start to star it and shit.
but now you have one peoblem you didn't have before: humans.

all sorts of shit:

people treating you like shit as if they were premium users.

people posting majestically written issues with titles like "people help, me no work, here" with bodies like "HAAAAAAAAAALP".

and if you have the blessing to work in the current js ecosystem, issues like "this doesn't work with esm, unpkg, cdnjs, babel, webpack, parcel, buble, A BROWSER".
with some occasional lunatic complaining about IE 4 having a very weird, obscure bug.

not the best prospect either.

Some people think that in the software industry there is no communication and everyone is glued to their screens doing their work. It really fucking pisses me off.

- We write documentation around our code more than actual code so that we can communicate with other developers better.

- We use version control and pull requests to make sure our work is at the required level and it is approved.

- We invented UML to communicate our technical understanding to less technical people.

- We sometimes have more client meetings than doctors have patients. In which we have deal with clients worse than patients.

- We conduct keynotes and conferences and hackathons to bring together communities.

These are just a few things from the top of my head so next time you think of saying that the IT or software professionals don't have "much" communication you better fucking educate yourself as to what the profession actually is.

Why the fuck are the setup instructions for the repo for Mac only?!! Oh, because everybody on the previous team used a Mac?!

Have you dick heads ever considered the possibility of new developers for the university module website not having a Mac??

And fuck your documentation too, half the fixes for setup problems mentioned inside the page doesn’t work. CS freshmen can write better documentation than you guys.

PS: that website and db is still not set up and setups should never take more than a day

TLDR; Go to bottom of post.

Around this time two years ago was the start of my group project in University. The project was to write an app in android and have a web side to it too. The group was to be overseen by a member of staff. The first meeting was introductions and to look at the spec, during the second we were to decide a group leader (PM) and other positions.
A person I shall call BD and I volunteered for PM. I didn't have experience with leadership but wanted some, and was the only one with confidence in android, the biggest part of the system. I got four of the votes.
BD, with his scouts experience, not being afraid to breathe down people's necks and bash some heads together, and having been PM last year, with his group receiving 69% (he failed the year and was resitting), earned 5. One guy was missing.
When it came to sorting out roles and responsibilities, BD confessed to not being a strong coder but that he'd help here and there. His role was planning our deadlines, doing our Gantt chart for deliverables, and was supposed to write a really detailed spec. He didn't have it at the meeting of the next week, as it was still in the works, and never messaged anyone. Next week he turned up with a Gantt chart of 1A4 page that only included the deadlines and deliverables in the spec, with three colours. One for android team, one for DB guy, and one for web team.
The guy who didn't turn up for voting got a girlfriend, a job at mcdonalds and did barely a thing. One guy in the web team did everything, carrying his friend who wouldn't do work (and also got swept out to see in a rubber boat with one of his bros lol (he was rescued)), and even though I'd done android dev I wasn't as quick a learner as two others in the team. Out of 10 people, 6 did real work.
The web guys stopped coming to meetings as they were taken over by android talk, and as we were quite behind, BG tried yellow carding them. They turned around with the website pretty much done, this one guy doing more than the 4 of us on android had. Yellow card lifted. We'd already complained about BD and his lack of everything (except screen brightness as he sat at the front of the lecture theatres with his wide brimmed hat looking at 9gag and videos (remembering he said he was resitting that year)) but grew a stronger dislike. Found out that he spent most of his time with his gf at our secretary/fellow android dev's house. Come coding week, he disappears entirely, only to attend meetings. He gave us a shell of the android code used for his previous year's project (along with documentation, complete with names and dates of updates, most of them (including the planning ones BD was supposed to do) bearing either one of two names. It was behind where we were at the time and had a lot of differences to our spec, and if we had used it BD may have used that to pull us down with him if things went wrong. He resurfaced at the end with the final documentation of how we'd all done, including reports on how each member had performed, which we were supposed to have reviewed. Our main, most proficient dev he accused of being irritable and brash, and a bad communicator. He was Norwegian, his voice was just a bit gruff, and he was driven and didn't waste time. He bashed the web team for not turning up, and had already been rude and unhelpful to everyone who voted for him in the first place.
In our own reports we all devoted paragraphs to delicately describing his contributions, excluding his suggestion that we use the code he gave us. Before we had our results and our work was completed, he individually kicked us from our group's facebook group and unfriended us.
Our 43% mark at the end, coupled with his -40% penalty from the red card we had him on, felt good, but not as good as a better result would have, especially as the fool that was BD would be inflicted on a group a third time. He changed to some other course after that year finished, so he must have failed his resit of second year.
During third year, a friend of mine who was PM for a group that passed well passed other things with too slim a margin to be happy, so chose to resit the year. He didn't have to do the group project again, and had that time free. But BD had to resit. His group had 69%. A yellow card with a 20% deduction wouldn't do it, so he MUST have had a red card as PM his previous year. Well that didn't come up when he claimed credit for his team's 69% during elections... My housemate's compsci boyfriend 2 years up overheard me talking about him, he was in 1st year with BD. BD failed and resat 1st year too. 4 years and he couldn't make anything stick. I feel bad for him through understanding the pains lack of work and internet distraction bring, and unfortunately I can't wish bad things on him because he brings them on himself. I wish I never see his face again though.

TLDR; Guy in group project lies and is dishonest from start to finish, getting PM pos by 1 vote. Gets what he earns.

Dear people who create frameworks and libraries,

Please don't advertise your stuff as 'super easy to use', 'incredibly lightweight', 'no configuration needed', 'seamless integration' and shit like this. We all know it's a big fat fucking lie. Just be honest and write 'it supposed to be all-purpose but won't solve your problem', 'a huge fucking chaotic mess', 'slow as shit', 'will eat up all your resources', 'might be good but we've lost the documentation' or 'actually worse than vanilla'. If you'd do this, the world would be a better place.

Thanks,

One of the things I have no fucking patience for is bureaucracy. For the last year I've been working for a company I have no problem with, I like the place and I like the people here. Recently I was contacted by another company and offered a better salary to work for them. I was open about it with my boss and we both accorded that I will receive the same salary to stay (It was ok to me since I feel comfortable here), but in order to do that I'll have to sign a new contract. Ok, no big deal. Few days later a HR girl contacts me to send her all the documentation needed to elaborate a contract, and I was like 'You guys already have all my documents, been working here for a year'. But Ok, I tried not to be picky and just sent her everything again. Then she requests online psychometric tests, sends a shitload of formats to fill, like personal references, their company-custom resume format, privacy policies, and many more stupid and irrellevant paperwork nobody should need when a person has been working for you for a year and you want him to stay. I really tried to be patient and do everything the HR girl wanted me to do, but for one reason or other, she kept rejecting the formats I was sending (I had to download, print, sign, scan and resend many of them). We've been wrestling for an entire fucking week over this shit via email and she can't just write a new contract, make me sign it and leave me the fuck alone. The last thing she compained about was a stupid personal reference format I didnt scan with my signature on. This other company wants me to start next monday. I guess the next document I'll be sending her will be my resignation letter.

tldr:
first year in college we programmed 24 hrs straight to fix somebody's mess before the deadline. Decided not to screw him over, instead he claimed to have done everything and we failed the assignment.

Long version:
var group= new[]{"Mike", "Gavin", "Gus", "I", "Ben" };
var client = "Jack"';

First year of college we had an assignment to make a web program for somebody.
Ben wanted to join our group and he already knew a client so we let him join.

After joining Ben wanted to be project lead, but we already decided Mike based on his experience.
Ben claimed to be much better in every way than Mike at and kept coming with stuff the following weeks why we should make him project lead. He kept pointing out when Mike did something wrong and he even came with an audio file where he clearly made jack say that he wanted Ben to be project lead .
After that we were all a bit pissed and told him that he should get it in his head that he was not going to be project lead and just start working on his part of the assignment.

We also found out that Ben was a documentation addict, what we could write in a small paragraph, he wrote a whole page about it. No joke, I rewrote a page of his in 5-6 rows with the same information in it.
No problem you thing, wrong! Because of this he kept bothering us arguing and claiming that our documentation was wrong because it was to short.

In the week of the deadline we asked Ben if he was also done, and told us that he was done for a while now.

The day before the deadline we came to school thinking we only had to do some merging and finishing up documentation.
Then we found out that Ben has almost nothing, and what he had the IDE was screaming that it was incorrect, spaces in Id's and css class names for instance. A really good programmer, my ass!
We were so pissed off at this point, but we had 24 hrs and needed to come up with a plan to fix it.

We decided that Mike and I were going to fix Ben his shit in the coming 24 hrs and Ben was going to make our last bit of documentation because we would not have the time for that, Especially if we had to argue with him like we had to do for each bit of documentation. Gus did not have time and Gavin could not program on his own yet, he wanted to help, but helping him help us would cost more time than we had.

We all went home after that and Mike and I started to program 24 hours straight while in a Skype call, making what Ben had 2 months for. Shortly before the deadline Mike looked at our finishing up documentation received from Ben and told me it was "Okay" and zipped everything up and uploaded it to school with a few minutes to spare.

After that we thought everything was good, we made Ben's part work and delivered it in time. We also decided not to throw Ben under the bus, because this would hurt all our grades because we did not work good as a group since we should have noticed it earlier.

A few weeks go by till the assessment.
The assessment start with asking if we want individual grades or as a group when you all think you did equal amount. We choose as a group, because if we chose individual not only Ben but also Gavin would get a lower grade and we did not think that was fair because he tried so hard.

We demo the product and the teachers are positive. When the teachers start about the documentation, the first thing they tell is that they found something interesting in the documentation, and they read it to us:

"I, Ben, have made all the documentation because my group did not want to."

That was so far from the truth, we all did make our documentation about the parts we made. Yes he did do overall a little bit more because every single bit of documentation we had to argue with him, so every time he volunteers to make it, we would all agree. And he made Mike's and i's last bit of documentation.

Telling the teachers on that point would not have mattered, it would only have hurt is in another way, so we did not and all failed the assignment. And we all felt like to strangle him.
This is now a few years back, but i still want too.

AI is the future, and it's a future I want to be part of.

This week was very stressful, beside my usual depression and personal issues, I've received a lot of difficult tasks at work, to do in a very short amount of time.
Things I never did, tecnologies I've never used, and for a potential client that is critical for the company at this period in time, and if we won't be able to satisfy their requests we could go bankrupt really soon.
A lot of responsibility, almost no time and a person not competent enough to do it (me), especially on a hurry.

I couldn't sleep in these days, I couldn't think peacefully, concentrate to find the best solutions. I had really bad thoughts.

I couldn't find any useful solution online, on stackoverflow, forums, etc. and I spent hours searching them.

For who knows me here on devRant, probably knows also that I tend to work with old legacy code and dead languages as VB6 and VB.NET.
So integrate "new fancy stuff" isn't that easy and there are no documentation and examples to relay on.
I had fear to even try to understand the documentation (for other languages) and try to write code for it… I was panicking.

With no more ideas, I've decided to try to ask ChatGPT for help.

In maybe 3 or 5 seconds it was able to generate the solution, in VB.NET, with comments and all the explanation needed to understand it and integrate it correctly in my software.
With a few other requests it was able to change it to make it fit better my scenarios.

It's truely unbelivable how the tecnology advanced in the last years, how a computer on the other side is able to reply to my questions with answers that I couldn't find anywhere, because they probably never existed for my case, in VB.NET especially.

ChatGPT made my day, and allowed me to end this stressful moment and give me time to relax and focus on more important personal stuff this weekend.

.net 1.1 had the best documentation ever written. Microsoft spent an enormous amount of money and a dedicated team of skilled engineers just to write them. It was kind of a great time to be a developer, even though the technology is much better now. The current reliance on community docs doesn't hold up as well.

So....
I was just told why the company's code has no documentation...

Quote: "It enforces devs to write simpler/better code"

Oh and added bonus - the whole backend is PHP with a bunch of tweaked libraries.

So I've been working as an operator in IBM for a year now. Two months after my onboard our team got an onboarding freeze. Since then more than a half of the team left and more are supposed to go, soo there is a problem covering all the workload. I volunteered to take 4th customers workload (out of 4 customers our team supports) because I already knew most of the work that is done there.
At a one-to-one meeting with my manager I asked for a little raise, because I have the 4th customer, I take other peoples shift anytime they need to take a free day, I update the documentation regularly, I write scripts for coworkers for installing software/automating what can be automated (and I'm the youngest here...) bla bla, telling him that I think I do a lot for the team and I deserve it. He told me that he would rather take away one of the customers workload. I rolled my eyes and went with it.
Two days later this asshole gave a raise to a guy, who was onboarding with me, because he wanted to motivate him. That very same day he told us that it seems like two customers are going to merge into one workload.
I'm so pissed because of this. I do my best all the time so I can get promoted to 2nd level linux team (I'm kinda one foot there) but the freeze is still preventing me to go. I'm already so tired of dealing with the bullshit of customer not knowing their own infrastructure, shitstorms of tickets during changes after level 2 didn't set maintenance mode again, repairing coworkers linux boxes because they don't know better and I'm so pissed at this un-initiative dickhead of a manager that gives a raise to lazy people.

Take the laziest person in the world and ask him/her to write an API documentation. He/she would do a better job than Apple

So, I've had a personal project going for a couple of years now. It's one of those "I think this could be the billion-dollar idea" things. But I suffer from the typical "it's not PERFECT, so let's start again!" mentality, and the "hmm, I'm not sure I like that technology choice, so let's start again!" mentality.

Or, at least, I DID until 3-4 months ago.

I made the decision that I was going to charge ahead with it even if I started having second thoughts along the way. But, at the same time, I made the decision that I was going to rely on as little external technology as possible. Simplicity was going to be the key guiding light and if I couldn't truly justify bringing a given technology into the mix, it'd stay out.

That means that when I built the front end, I would go with plain HTML/CSS/JS... you know, just like I did 20+ years ago... and when I built the back end, I'd minimize the libraries I used as much as possible (though I allowed myself a bit more flexibility on the back end because that seems to be where there's less issues generally). Similarly, any choice I made I wanted to have little to no additional tooling required.

So, given this is a webapp with a Node back-end, I had some decisions to make.

On the back end, I decided to go with Express. Previously, I had written all the server code myself from "first principles", so I effectively built my own version of Express in other words. And you know what? It worked fine! It wasn't particularly hard, the code wasn't especially bad, and it worked. So, I considered re-using that code from the previous iteration, but I ultimately decided that Express brings enough value - more specifically all the middleware available for it - to justify going with it. I also stuck with NeDB for my data storage needs since that was aces all along (though I did switch to nedb-promises instead of writing my own async/await wrapper around it as I had previously done).

What I DIDN'T do though is go with TypeScript. In previous versions, I had. And, hey, it worked fine. TS of course brings some value, but having to have a compile step in it goes against my "as little additional tooling as possible" mantra, and the value it brings I find to be dubious when there's just one developer. As it stands, my "tooling" amounts to a few very simple JS scripts run with NPM. It's very simple, and that was my big goal: simplicity.

On the front end, I of course had to choose a framework first. React is fine, Angular is horrid, Vue, Svelte, others are okay. But I didn't want to bother with any of that because I dislike the level of abstraction they bring. But I also didn't want to be building my own widget library. I've done that before and it takes a lot of time and effort to do it well. So, after looking at many different options, I settled on Webix. I'm a fan of that library because it has a JS-centric approach. There's no JSX-like intermediate format, no build step involved, it's just straight, simple JS, and it's powerful and looks pretty good. Perfect for my needs. For one specific capability I did allow myself to bring in AnimeJS and ThreeJS. That's it though, no other dependencies (well, at first, I was using Axios because it was comfortable, but I've since migrated to plain old fetch). And no Webpack, no bundling at all, in fact. I dynamically load resources, which effectively is code-splitting, and I have some NPM scripts to do minification for a production build, but otherwise the code that runs in the browser is what I actually wrote, unlike using a framework.

So, what's the point of this whole rant?

The point is that I've made more progress in these last few months than I did the previous several years, and the experience has been SO much better!

All the tools and dependencies we tend to use these days, by and large, I think get in the way. Oh, to be sure, they have their own benefits, I'm not denying that... but I'm not at all convinced those benefits outweighs the time lost configuring this tool or that, fixing breakages caused by dependency updates, dealing with obtuse errors spit out by code I didn't write, going from the code in the browser to the actual source code to get anywhere when debugging, parsing crappy documentation, and just generally having the project be so much more complex and difficult to reason about. It's cognitive overload.

I've been doing this professionaly for a LONG time, I've seen so many fads come and go. The one thing I think we've lost along the way is the idea that simplicity leads to the best outcomes, and simplicity doesn't automatically mean you write less code, doesn't mean you cede responsibility for various things to third parties. Those things aren't automatically bad, but they CAN be, and I think more than we realize. We get wrapped up in "what everyone else is doing", we don't stop to question the "best practices", we just blindly follow.

I'm done with that, and my project is better for it!

I really really hope that no one post this,a friend texted it to me and I wanted to share it because made my day.

Idk where it comes, so feel free if know where this came from to post it:

//FUN PART HERE
# Do not refactor, it is a bad practice. YOLO

# Not understanding why or how something works is always good. YOLO

# Do not ever test your code yourself, just ask. YOLO

# No one is going to read your code, at any point don’t comment. YOLO

# Why do it the easy way when you can reinvent the wheel? Future-proofing is for pussies. YOLO

# Do not read the documentation. YOLO

# Do not waste time with gists. YOLO

# Do not write specs. YOLO also matches to YDD (YOLO DRIVEN DEVELOPMENT)

# Do not use naming conventions. YOLO

# Paying for online tutorials is always better than just searching and reading. YOLO

# You always use production as an environment. YOLO

# Don’t describe what you’re trying to do, just ask random questions on how to do it. YOLO

# Don’t indent. YOLO

# Version control systems are for wussies. YOLO

# Developing on a system similar to the deployment system is for wussies! YOLO

# I don’t always test my code, but when I do, I do it in production. YOLO

# Real men deploy with ftp. YOLO

So YOLO Driven Development isn’t your style? Okay, here are a few more hilarious IT methodologies to get on board with.

*The Pigeon Methodology*
Boss flies in, shits all over everything, then flies away.

*ADD (Asshole Driven Development)*
An old favourite, which outlines any team where the biggest jerk makes all the big decisions. Wisdom, process and logic are not the factory default.

*NDAD (No Developers Allowed in Decisions)*
Methodology Developers of all kinds are strictly forbidden when it comes to decisions regarding entire projects, from back end design to deadlines, because middle and top management know exactly what they want, how it should be done, and how long it will take.

*FDD (Fear Driven Development)*
The analysis paralysis that can slow an entire project down, with developments afraid to make mistakes, break the build, or cause bugs. The source of a developer’s anxiety could be attributed to a failure in sharing information, or by implicating that team members are replaceable.

*CYAE (Cover Your Ass Engineering)*
As Scott Berkun so eloquently put it, the driving force behind most individual efforts is making sure that when the shit hits the fan, you are not to blame.

We use at our company one of the largest Python ORM and dont code ourselfs on it, event tough I can code. Its some special contract which our General Manager made, before we as Devs where in the Project and everything is provided from the external Company as Service. The Servers are in our own Datacenter, but we dont have access.

We have our Consultants (Project Manager) as payd hires and they got their own Devs.

Im in lead of Code Reviews and Interfaces. Also Im in the "Run" Team, which observes, debuggs and keeps the System alive as 3rd-Level (Application Managers).

What Im trying to achieve is going away from legacy .csv/sftp connections to RestAPI and on large Datasets GraphQL. Before I was on the Project, they build really crappy Interfaces.

Before I joined the Project in my Company, I was a Dev for a couple of Finance Applications and Webservices, where I also did coding on Business critical Applications with high demand Scaling.

So forth, I was moved by my Boss over to the Project because it wasn't doing so well and they needed our own Devs on it.

Alot of Issues/Mistakes I identified in the Software:
- Lots of Code Bugs
- Missing Process Logic
- No Lifecycle
- Very fast growing Database
- A lot of Bad Practices

Since my switch I fixed alot of bugs, was the man of the hour for fixing major Incidents and so on so forth. A lot of improvements have been made. Also the Team Spirit of 15+ People inside the Project became better, because they could consult me for solutions/problems.

But damn I hate our Consultants. We pay them and I need to sketch the concepts, they are to dumb for it. They dont understand Rest or APIs in general, I need to teach them alot about Best Practices and how to Code an API. Then they question everything and bring out a crooked flawed prototype back to me.

WE F* PAY THEM FOR BULLCRAP! THEY DONT EVEN WRITE DOCUMENTATION, THEY ARE SO LAZY!

I even had a Meeting with the main Consultant about Performance Problems and how we should approach it from a technical side and Process side. The Software is Core Business relevant and its running over 3 Years. He just argumented around the Problem and didnt provide solutions.

I confronted our General Manager a couple of times with this, but since 3 Years its going on and on.

Im happy with my Team and Boss, they have my back and I love my Job, but dealing with these Nutjobs of Consultants is draining my nerves/energy.

Im really am at my wits end how to deal with this anymore? Been pulling trough since 1 year. I wanna stay at my company because everything else besides the Nutjob Consultants is great.

I told my Boss about it a couple of times and she agrees with me, but the General Manager doesnt let go of these Consultants.

Even when they fuck up hard and crash production, they fucking Bill us... It's their fault :(

When the CTO/CEO of your "startup" is always AFK and it takes weeks to get anything approved by them (or even secure a meeting with them) and they have almost-exclusive access to production and the admin account for all third party services.

Want to create a new messaging channel? Too bad! What about a new repository for that cool idea you had, or that new microservice you're expected to build. Expect to be blocked for at least a week.

When they also hold themselves solely responsible for security and operations, they've built their own proprietary framework that handles all the authentication, database models and microservice communications.

Speaking of which, there's more than six microservices per developer!

Oh there's a bug or limitation in the framework? Too bad. It's a black box that nobody else in the company can touch. Good luck with the two week lead time on getting anything changed there. Oh and there's no dedicated issue tracker. Have you heard of email?

When the systems and processes in place were designed for "consistency" and "scalability" in mind you can be certain that everything is consistently broken at scale. Each microservice offers:

1. Anemic & non-idempotent CRUD APIs (Can't believe it's not a Database Table™) because the consumer should do all the work.
2. Race Conditions, because transactions are "not portable" (but not to worry, all the code is written as if it were running single threaded on a single machine).
3. Fault Intolerance, just a single failure in a chain of layered microservice calls will leave the requested operation in a partially applied and corrupted state. Ger ready for manual intervention.
4. Completely Redundant Documentation, our web documentation is automatically generated and is always of the form //[FieldName] of the [ObjectName].
5. Happy Path Support, only the intended use cases and fields work, we added a bunch of others because YouAreGoingToNeedIt™ but it won't work when you do need it. The only record of this happy path is the code itself.

Consider this, you're been building a new microservice, you've carefully followed all the unwritten highly specific technical implementation standards enforced by the CTO/CEO (that your aware of). You've decided to write some unit tests, well um.. didn't you know? There's nothing scalable and consistent about running the system locally! That's not built-in to the framework. So just use curl to test your service whilst it is deployed or connected to the development environment. Then you can open a PR and once it has been approved it will be included in the next full deployment (at least a week later).

Most new 'services' feel like the are about one to five days of writing straightforward code followed by weeks to months of integration hell, testing and blocked dependencies.

When confronted/advised about these issues the response from the CTO/CEO
varies:

(A) "yes but it's an edge case, the cloud is highly available and reliable, our software doesn't crash frequently".
(B) "yes, that's why I'm thinking about adding [idempotency] to the framework to address that when I'm not so busy" two weeks go by...
(C) "yes, but we are still doing better than all of our competitors".
(D) "oh, but you can just [highly specific sequence of undocumented steps, that probably won't work when you try it].
(E) "yes, let's setup a meeting to go through this in more detail" *doesn't show up to the meeting*.
(F) "oh, but our customers are really happy with our level of [Documentation]".

Sometimes it can feel like a bit of a cult, as all of the project managers (and some of the developers) see the CTO/CEO as a sort of 'programming god' because they are never blocked on anything they work on, they're able to bypass all the limitations and obstacles they've placed in front of the 'ordinary' developers.

There's been several instances where the CTO/CEO will suddenly make widespread changes to the codebase (to enforce some 'standard') without having to go through the same review process as everybody else, these changes will usually break something like the automatic build process or something in the dev environment and its up to the developers to pick up the pieces. I think developers find it intimidating to identify issues in the CTO/CEO's code because it's implicitly defined due to their status as the "gold standard".

It's certainly frustrating but I hope this story serves as a bit of a foil to those who wish they had a more technical CTO/CEO in their organisation. Does anybody else have a similar experience or is this situation an absolute one of a kind?

I found the best text editor for basic code fixing

For a couple of days, I was looking for a simple terminal-based text editor for taking simple code notes or basic code fixing kinds of stuff.

As an aspiring developer, I really like the concept of coding without touching the mouse.

So I downloaded the king of CLI text editors, Vim.

Now, guess what happened.

Yeah, you're right. I stuck inside vim and couldn't even quit from there.

Then, I started watching a bunch of tutorials and started reading vim's documentation.

But then I realized, I have to learn a lot of things only to operate vim and it's a pretty lengthy process.

At that time, I really needed a very simple text editor for doing basic stuff.

But, vim is not simple... you know :)

So, I had to come back to 'nano' & I was not happy enough to write codes by using 'nano'.

Suddenly, I discovered another really cool text editor called 'micro'.

It's really awesome.

It's not as advanced as vim but definitely a lot better than nano.

Micro is an open-source command-line text editor created by Zachary Yedidia.

Some basic key points of Micro:
1. It's really easy to operate.
2. It has different colours and highlights.
3. It supports syntaxes for over 70+ programming languages.
4. It has mouse support.
5. Plugins & colour schemes.

The best thing for me is colour schemes & screen split support.

Check out my full article on DEV - @souviktests.

Have you ever gotten a task where you have to modify some existing code, and to get it to work the way it needs to you have to write some ugly ass code?

And I'm talking FUGLY ass code. The kind where every brain cell you have screams to refactor it all so that your code won't be so ugly and you can live with yourself. But you only wrote it that way because some numbnuts who was fired a year ago designed it that way, and left zero commentary or documentation on his reasoning ("sELf-dOcUmeNtiNg cOde, bRuH!").

It doesn't pose any sort of risk with regards to security or resource management or efficiency, or really even faulty logic. It just looks fucking awful, my brain can instantly see better ways to design it and I don't want history to tie my name to it.

But also the system is being gutted and retired within a matter of months, so maintenance won't even be a concern; and you know that you have a lot of other large tasks that need your attention too, and to refactor will ultimately prove to be a time sink.

I mean ultimately, I know what I need to do, but I guess it's a pride thing. Just makes me feel icky.

Python ecosystem drives me nuts!

Not the language tho, i kinda like it, and some features are damn straight awesome.

But ecosystem... man!

The way ppl write code in it, the lack of documentation (or in quality of it)...

I recently wanted to check how library does one thing (debug purposes), and not only i had to track some method up 3 classes, the other method i hunted only by signature and still i have no idea how it ends up being accessible where it should...

"Explicit is better than implicit" my ass...

Also dev managed to make the code very unreadable. In Python. Language with such strong opinions about code formatting. HOW ?!!

And the worst part is, it wasn't that big of a library and didn't really need the full freaking Enterprise OOP treatment with layers over layers of generally named classes and fucked up architecture.

FUCK THAT LIB, FUCK THAT DEV, FUCK IT ALL !!!

PS.
Project seems to be abandoned for a year or two, so there is hardly an option to fix things with the author sadly :(

If a team uses multiple languages and stacks (Have, JS, Python) do you think it's better to have everyone use/constantly switch between them or have dedicated developers for each language (ie. 80% main, 20% others)?

--END QUESTION, ANSWER NOW BEFOREHAND CONTINUING---
---BEGIN RANT---

My boss likes keeping the team "will rounded" so everyone does everything. One month in working in Java, the next with Node web apps. When I switch to node, it takes like a week of "wtf doesn't it work.... what changed, is it a big?" And usually end it"oh right I remember I need to ..."

And also always... "How the fuck do I write tests in {some reading framework} again?"

So feels like everyone is just a generalist and no one is a master/has time to develop mastery. I don't know if it's just me (1/3 Senior developers on the team that has to do everything) or if I'm the only one that complains... Not that it makes a difference... (Only option to really be heard is to resign but I need to somewhere else to work and finding one is hard for personal reasons)

And well this is the biggest reason I would leave the team. No time for mastery, no standardization/shared knowledge (everyone does their own thing but probably not well and no time for testing or documentation; how the fuck does whatever you wrote work, how do we use it, what the fuck did you put in prod that does ... And where the fuck did you put it cuz it's not in ANY of our repos).

I always feel one day soon it will come crashing down and I can say "I told you so" but will then it's too late and I'll be there one cleaning it up... Again

Your time is better used somewhere else, let the intern write the documentation. While the project was transitioning to a whole new team with no one from the old one.

I was adding a new API integration into the product today, half of the API Documentation is written like shit, and has mistakes in them.

Okay, I kind of solved what ever errors there were in the documentation and got the API to give a response.
Tried to simulate an error response and all I get is 'Internal Server Error'.

What fucking pieces of shit wrote an API, which doesn't provide a correct error response.
I had to write to the support team in order to get everything clarified.
The elements that were indicated as optional should be there in the request it seems, if you don't want to enter any data for that, pass an empty string to it.
Atleast they could've given a proper error response / their documentation could've been better!

I've been working with Node and Typescript for a while now, and I wrote a wide array of very general utility functions. Examples include:
- Array.filter but you also get the residue array, it can also leave holes in both arrays if you want to join them later
- Array zipping and unzipping to and from tuples (especially valuable when you're manipulating the prop set with Object.entries() in a HOC
- Array maximum selection, with an optional mapper
- Cancelable promises, lazy promises, a promise that resolves when a given function on an object is called (excellent for DOM events), a timeout promise.
- A typed event with both immediate and microtask listeners depending on whether you need state guarantees (this idea I took from a Github gist and upgraded it)

I want to put them on NPM so I don't have to write them and their tests again, and so that if I ever think of an improvement it's easier to propagate it. Do you think I should release them as tiny individual packages which would be nice from a versioning standpoint, or should I make them into a compilation which would be a lot less work for me (and therefore would probably result in better documentation and more tests)?

Soooo I am an apprentice who just started his third year. Everybody in my team (3 ppl) left for better jobs.
I am now basically front and backend lead, teaching four new employees our restapi, web and javafx frontend.
At the same time I fix errors happening in production and develop new features.
I guess there are many great rants to come, so stay tuned :D
Going to write about things like tests that got disabled months ago after migrating to gradle, no documentation, finding out how to set up new development workstations with an outdated script missing important steps, management, print debugging in production and much more :)
Oh and it is not that bad, I learned more in the last month than in the two years before. (not saying my team was bad)

Is it normal to find yourself spending days sifting through documentation, often outdated, when learning new tools/frameworks as a developer? Sometimes finding myself doing this just to write 2 lines of code to interface something/configuration and I’m not sure if I’m better off just forcefully coding my own fix while knowing there’s a solution out there in the haystack.

Ticket: implement compression algorithm to crypto object x

Details: object to big, we must devise a way to compress it. A deflate algorithm should be added here, yada yada yada we did not have the time Yara yada...

Go see crypto provider's documentation... It has compression options... -_-

You lazy fucking stack overflow copy question dimwits!!! Jesus fucking Christ! This reached production like this shit, I've got clients complaining of the size of the payload because you are a bunch of lazy fucks who can't even read simple documentation!!!

I want to kill someone for wasting my time and patience... Don't call me for this kind of crap... I have better things to do!

I mean, the time it took you to write the ticket should suffice...

It is better to write almost all of the logic used in the code as comments/documentation.
Trust me.
It is a good thing. It increases Code readability.
Nobody is going to copy your logic and get hired in a high paying job or get promoted for that reason. People will come to know about your wit and will appreciate you instead.

Hopefully, simpler sintax.

And better documentation for every language/framework. Especially for the devs who are just starting, don't write documentation assuming everyone has been working with your framework for years!

That last one was more a rant than answering the actual question, but I needed to say it. It's been on my mind for a while 😑

Recently I have had to help our support team handle a variety of embedded development support tickets for a product line that is quite complex in nature. It is really starting become frustrating how common it is that the so-called “developers” that are using this product are so incompetent at requesting help in a proper/sane way. It is even more frustrating that some of these schmucks start acting up and stating bullshit statements like (para-phrasing) “OMG we have a ‘big opportunity’ and a deadline to meet”, “you need to help us faster”. These are also the same guys that are like “I know you have a free SDK that does everything correctly, but I want to write my own ‘pro’ driver written in my own ‘dumbass code style’. Oh and I am not going to follow documentation and not implement required functions and make you read my god awful code snippets to find out what I what I did wrong instead of reading the docs or comparing against the SDK.”

To anyone that behaves this way...fuck you! Just stop. Stop being a developer altogether. If your “opportunity” is so important, why the fuck are you half-assing your support ticket? Why are you making it SO DAMN DIFFICULT for someone to help support you! Give as much info as possible to prove your point or provide context to the problem you are having. In the majority of these tickets the dumbasses don’t even consider that relaying the product’s firmware version is relevant information, that a Wireshark (and/or logic analyzer) capture can be very useful to provide context to the type of operation being performed. Code snippets can be nice but only if there is sufficient context. We have had to ask one guy 3 times already for the FW version...what the flipping hell is wrong with you?!

Ug...I feel sorry for Support/FAEs sometimes dealing with customer bullshit drives me nuts and its a shame this stuff happens in a sector that should know better...Please don’t be like these devs. If you make a half-assed request it is only reasonable to expect a half-assed response and nothing more.

[POLL] How do you develop stuff?
1 - just write code. It doesn't need to be organized, it just need to work how you thought it would, and THEN you start organizing things, like editing/creating new files, letting things DRY, optimizing the sutff you did earlier;
OR
2 - you surgically write code, making sure you keep everything is organized from the beginning. Basically you only write when you are sure.

Or maybe it's a blend between the two or something.

I'm asking because I do like the #1 and I feel uncomfortable when people see my code when it's under development. It's a mess, there are tons of comments everywhere and a bunch of repetition. But, when I find the right stuff, I start writing modules to make my code work better, remove unnecessary things, add documentation, and so on.

My development process is not the best of the best, but I get things done with it.

doing documentation in word and having meetings about it, code reviews where people say great code quality with all good practices but... we would like to do it differently, reasons? less lines of code but real reason is not understanding design patterns, also 6 levels of hierarchy and wasted effort to prove that approach is good and considered as good practice just to be changed by someone who doesn't write code anymore. Decisions that other approach is better because they did it that way 10 years ago on last project where they were developers on totally different tech stack. dear friends, welcome to corporation!

when creating subtasks for my jira tasks, so PM can micromanage me better, i never know if he will criticize it for being "too fine granular, just write it in the comments" or for being "not detailed enough". also, on the one hand he criticizes team members for not having meaningful comments (e.g. "writing documentation"), on the other hand, he criticizes people that he doesn't know what they are doing. also, not to forget that i shouldn't have more than one task in progress ("it should be transparent what you're currently working on"), but then he randomly decides to set one of my tasks in progress even if this breaks his "one task at a time" rule. but i guess it's okay if he does it, because he's boss.

i honestly have no fucking clue how to please this guy lol

Was moved from frontend to backend. I am an absolute noob in java, code has no documentation, no formal training, code has cross repository dependencies and I have been assigned with a case and was asked to debug, felt like a pathetic piece of shit. One of those depressing days, but the good thing is we were moved here as an entire team and apparently everyone feels the same way 😂 which makes me feel better.

These are one of those short phase of "0 productivity" days, I wish Java god help me and let me write code with my usual speed, untill then I am going to feel miserable and bad about myself.

Back when I still was in my first internship and was still working my way through the fundamentals of programming, I given a web relay and asked to make it do something. The web relay let you write BASIC into a web page hosted by the device itself in order to program it. My task was to turn the relay on if a certain temperature threshold was met, and to turn off the relay (the relay would control an air intake system for cooling).

I learned the syntax of BASIC enough to get a basic (hah) script going, and dug into the relay documentation for other bits of info I needed. It definitely was no coding masterpiece, but I was able to program the damned thing to turn this blower on and off if the measured temperature was within a range. I discovered that there was a limit to how deep the conditionals would nest, and had to restructure my code to account for the limitation.

I've since gotten better at coding, but to accomplish that task as I was beginning my programming journey felt like a true accomplishment.

#Suphle Rant 6: Deptrac, phparkitect

This entry isn't necessarily a rant but a tale of victory. I'm no more as sad as I used to be. I don't work as hard as I used to, so lesser challenges to frustrate my life. On top of that, I'm not bitter about the pace of progress. I'm at a state of contentment regarding Suphle's release

An opportunity to gain publicity presented itself last month when cfp for a php event was announced last month. I submitted and reviewed a post introducing suphle to the community. In the post, I assured readers that I won't be changing anything soon ie the apis are cast in stone. Then php 7.4 officially "went out of circulation". It hit me that even though the code supports php 8 on paper, it's kind of a red herring that decorators don't use php 8 attributes. So I doubled down, suspending documentation.

The container won't support union and intersection types cuz I dislike the ambiguity. Enums can't be hydrated. So I refactored implementation and usages of decorators from interfaces to native attributes. Tried automating typing for all class properties but psalm is using docblocks instead of native typing. So I disabled it and am doing it by hand whenever something takes me to an unfixed class (difficulty: 1). But the good news is, we are php 8 compliant as anybody can ask for!

I decided to ride that wave and implement other things that have been bothering me:
1) 2 commands for automating project setup for collaborators and user facing developers (CHECK)
2) transferring some operations from runtime to compile/build TIME (CHECK)
3) re-attempt implementing container scopes

I tried automating Deptrac usage ie adding the newly created module to the list of regulated architectural layers but their config is in yaml, so I moved to phparkitect which uses php to set the rules. I still can't find a library for programmatically updating php filed/classes but this is more dynamic for me than yaml. I set out to implement their library, turns out the entire logic is dumped into the command class, so I can neither control it without the cli or automate tests to it. I take the command apart, connect it to suphle and run. Guess what, it detects class parents as violations to the rule. Wtflyingfuck?!

As if that's not bad enough, roadrunner (that old biatch!) server setup doesn't fail if an initialization script fails. If initialization script is moved to the application code itself, server setup crumbles and takes the your initialization stuff down with it. I ping the maintainer, rustacian (god bless his soul), who informs me point blank that what I'm trying to do is not possible. Fuck it. I have to write a wrapper command for sequentially starting the server (or not starting if initialization operations don't all succeed).

Legitimate case to reinvent the wheel. I restored my deleted decorators that did dependency sanitation for me at runtime. The remaining piece of the puzzle was a recursive film iterator to feed the decorators. I checked my file system reader for clues on how to implement one and boom! The one I'd written for two other features was compatible. All I had to do was refactor decorators into dependency rules, give them fancy interfaces for customising and filtering what classes each rule should actually evaluate. In a night's work (if you're discrediting how long writing the original sanitization decorators and directory iterator), I coupled the Deptrac/phparkitect library of my dreams. This is one of the those few times I feel like a supreme deity

Hope I can eat better and get some sleep. This meme is me after getting bounced by those three library rejections