As a developer, sometimes you hammer away on some useless solo side project for a few weeks. Maybe a small game, a web interface for your home-built storage server, or an app to turn your living room lights on an off.

I often see these posts and graphs here about motivation, about a desire to conceive perfection. You want to create a self-hosted Spotify clone "but better", or you set out to make the best todo app for iOS ever written.

These rants and memes often highlight how you start with this incredible drive, how your code is perfectly clean when you begin. Then it all oscillates between states of panic and surprise, sweat, tears and euphoria, an end in a disillusioned stare at the tangled mess you created, to gather dust forever in some private repository.

Writing a physics engine from scratch was harder than you expected. You needed a lot of ugly code to get your admin panel working in Safari. Some other shiny idea came along, and you decided to bite, even though you feel a burning guilt about the ever growing pile of unfinished failures.

All I want to say is:

No time was lost.

This is how senior developers are born. You strengthen your brain, the calluses on your mind provide you with perseverance to solve problems. Even if (no, *especially* if) you gave up on your project.

Eventually, giving up is good, it's a sign of wisdom an flexibility to focus on the broader domain again.

One of the things I love about failures is how varied they tend to be, how they force you to start seeing overarching patterns.

You don't notice the things you take back from your failures, they slip back sticking to you, undetected.

You get intuitions for strengths and weaknesses in patterns. Whenever you're matching two sparse ordered indexed lists, there's this corner of your brain lighting up on how to do it efficiently. You realize it's not the ORMs which suck, it's the fundamental object-relational impedance mismatch existing in all languages which causes problems, and you feel your fingers tingling whenever you encounter its effects in the future, ready to dive in ever so slightly deeper.

You notice you can suddenly solve completely abstract data problems using the pathfinding logic from your failed game. You realize you can use vector calculations from your physics engine to compare similarities in psychological behavior. You never understood trigonometry in high school, but while building a a deficient robotic Arduino abomination it suddenly started making sense.

You're building intuitions, continuously. These intuitions are grooves which become deeper each time you encounter fundamental patterns. The more variation in environments and topics you expose yourself to, the more permanent these associations become.

Failure is inconsequential, failure even deserves respect, failure builds intuition about patterns. Every single epiphany about similarity in patterns is an incredible victory.

Please, for the love of code...

Start and fail as many projects as you can.

"Let's do some pair programming! It will be fun!"

... Fuck no.

Either I start coding and you open a beer, or the other way around. And sure, I do not mind doing each other's code reviews. I respect your feedback.

But I can't look over your shoulder while you misspell keywords. When I write code, I search, try, debug and play at a high speed.

I'm an impressionist/surrealist writing messy passionate functions, breaking lots of things with broad paintbrush strokes before finishing it into detailed perfection. I remember all the places in the code I need to work on, and cover everything with tests.

You're a baroque coder, sometimes even a hyperrealist, with your two-finger 10 wpm typing, writing code strictly line-by-line, decorating every statement with the right checks & typehints in advance. You can not keep two functions in your head at the same time. You write tests reluctantly, but you hate that I barely plan. You plan everything, including your pee breaks.

As a coworker I respect you.

But there is no bigger hell than pair programming with you.

Things I wish I could tell my 18 year old self.

1) Accept you will make mistakes.
2) Truly learn the language you are using.
3) Write idiomatic code for the language you are using.
4) Be upfront about not knowing something.
5) Don't let not knowing something stop you from learning it.
6) None of us knew X until we learned it.
7) Understand your strengths and weaknesses as a developer, play to them.
8) Be willing to try new things.
9) X language isn't ALWAYS the best choice, X paradigm isn't ALWAYS the best choice. Choose wisely.
10) You won't know everything, but you might know more than others.
11) Your ideas and ego don't matter more than ensuring the product works.
12) "Perfection is the enemy of the good [enough]" - Voltaire
13) "Perfection is not achieved when there's nothing more to add, but when there's nothing more to remove." - Einstein.
14) Conflicts happen, deal with it.
15) Develop a toolset and really learn them.
16) Try new tools, they may prove better than what you were using.
17) Don't manage your own memory unless you absolutely have to, you are probably not smarter than the collective intelligence of the team that built the various garbage collection methods.
18) People can be dicks, especially online.
19) If you are new and people are being dicks to you, did you skip past the irc message about etiquette? If you did, you're the dick in this situation.
20) It can be tough, but it is fun, so have fun!

A few of Stux's !dev pet peeves

1) People that walk slow as fuck in the middle of a side walk. Like hurry uppppp. I've gotta get 0.5 miles in like 8 minutes and you blocking the walkway doesn't help.

2) People that don't understand how side walks work. Treat it like the fucking road. ⬇️⬆️ Is the pattern in which you should walk. It's not rocket science.

3) People that start walking up the bus steps as I'm clearly walking forward to get off. Ffs let me off and THEN get on you stupid bitch

4) people that bike or ride their skateboard/longboard around campus but are moving slower than I am while walking. If you're gonna do that hop the fuck off and carry the damn thing.

5) people that don't try to solve an issue with their code on their own BEFORE they call the professor over. (There goes the !dev lol)

6) people that act like their favorite musician or athelete or actor or anyone fucking famous they play kiss ass with can't be criticized. Just bc they're famous and/or good at what they do sure asf doesn't make them perfection and I retain the right to voice my opinion.

My name is Stuxnet and you're watching Disney Channel.

You refactor after there's code. You can't have clean code if there isn't code to be cleaned to begin with. Code first. Think of perfection later.

Craziest bug, not so much in the sense of what it was (although it was itself wacky too), but in what I went through to fix it.

The year was 1986. I was finishing up coding on a C64 demo that I had promised would be out on a specific weekend. I had invented a new demo effect for it, which was pretty much the thing we all tried to do back then because it would guarantee a modicum of "fame", and we were all hyper-ego driven back then :) So, I knew I wanted to have it perfect when people saw it, to maximize impressiveness!

The problem was that I had this ONE little pixel in the corner of the screen that would cycle through colors as the effect proceeded. A pixel totally apart from the effect itself. A pixel that should have been totally inactive the entire time as part of a black background.

A pixel that REALLY pissed me off because it ruined the utter perfection otherwise on display, and I just couldn't have that!

Now, back then, all demos were coded in straight Assembly. If you've ever done anything of even mild complexity in Assembly, then you know how much of a PITA it can be to find bugs sometimes.

This one was no exception.

This happened on a Friday, and like I said, I promised it for the weekend. Thus began my 53 hours of hell, which to this day is still the single longest stretch of time straight that I've stayed awake.

Yes, I spent literally over 2+ days, sitting in front of my computer, really only ever taking bio breaks and getting snacks (pretty sure I didn't even shower)... all to get one damn pixel to obey me. I would conquer that f'ing pixel even if it killed me in the process!

And, eventually, I did fix it. The problem?

An 'i' instead of an 'l'. I shit you not!

After all these years I really don't remember the details, except for the big one that sticks in my mind, that I had an 'i' character in some line of code where an 'l' should have been. I just kept missing it, over and over and over again. I mean, I kinda understand after many hours, your brain turns to mush. and you make more mistakes, so I get missing it after a while... but missing it early on when I was still fresh just blows my mind.

As I recall, I finally uploaded the demo to the distro sight at around 11:30pm, so at least I made my deadline before practically dropping dead in bed (and then having to get up for school the next morning- D'oh!). And it WAS a pretty impressive demo... though I never did get the fame I expected from it (most likely because it didn't get distributed far and wide enough).

And that's the story of what I'd say was my craziest bug ever, the one that probably came closest to killing me :)

> Worst work culture you've experienced?

It's a tie between my first to employers.

First: A career's dead end.
Bosses hardly ever said the truth, suger-coated everything and told you just about anything to get what they wanted. E.g. a coworker of mine was sent on a business trip to another company. They had told him this is his big chance! He'd attend a project kick-off meeting, maybe become its lead permanently. When he got there, the other company was like "So you're the temporary first-level supporter? Great! Here's your headset".

And well, devs were worth nothing anyway. For every dev there were 2-3 "consultants" that wrote detailed specifications, including SQL statements and pseudocode. The dev's job was just to translate that to working code. Except for the two highest senior devs, who had perfect job security. They had cooked up a custom Ant-based build system, had forked several high-profile Java projects (e.g. Hibernate) and their code was purposely cryptic and convoluted.
You had no chance to make changes to their projects without involuntarily breaking half of it. And then you'd have to beg for a bit of their time. And doing something they didn't like? Forget it. After I suggested to introduce automated testing I was treated like a heretic. Well of course, that would have threatened their job security. Even managers had no power against them. If these two would quit half a dozen projects would simply be dead.

And finally, the pecking order. Juniors, like me back then, didn't get taught shit. We were just there for the work the seniors didn't want to do. When one of the senior devs had implemented a patch on the master branch, it was the junior's job to apply it to the other branches.

Second: A massive sweatshop, almost like a real-life caricature.
It was a big corporation. Managers acted like kings, always taking the best for themselves while leaving crumbs for the plebs (=devs, operators, etc). They had the spacious single offices, we had the open plan (so awesome for communication and teamwork! synergy effects!). When they got bored, they left meetings just like that. We... well don't even think about being late.
And of course most managers followed the "kiss up, kick down" principle. Boy, was I getting kicked because I dared to question a decision of my boss. He made my life so hard I got sick for a month, being close to burnout. The best part? I gave notice a month later, and _he_still_was_surprised_!
Plebs weren't allowed anything below perfection, bosses on the other hand... so, I got yelled at by some manager. Twice. For essentially nothing, things just bruised his fragile ego. My bosses response? "Oh he's just human". No, the plebs was expected to obey the powers that be. Something you didn't like? That just means your attitude needs adjustment. Like with the open plan offices: I criticized the noise and distraction. Well that's just my _opinion_, right? Anyone else is happily enjoying it! Why can't I just be like the others? And most people really had given up, working like on a production line.

The company itself, while big, was a big ball of small, isolated groups, sticking together by office politics. In your software you'd need to call a service made by a different team, sooner or later. Not documented, noone was ever willing to help. To actually get help, you needed to get your boss to talk to their boss. Then you'd have a chance at all.

Oh, and the red tape. Say you needed a simple cable. You know, like those for $2 on Amazon. You'd open a support ticket and a week later everyone involved had signed it off. Probably. Like your boss, the support's boss, the internal IT services' boss, and maybe some other poor sap who felt important. Or maybe not, because the justification for needing that cable wasn't specific enough. I mean, just imagine the potential damage if our employees owned a cable they shouldn't!

You know, after these two employers I actually needed therapy. Looking back now, hooooly shit... that's why I can't repeat often enough that we devs put up with way too much bullshit.

So at this startup i was single iOS dude age 34, android had 1.5 dudes, one older, one you ger. That 0.5 younger was tech director, really good, so they churned for two guys. Millenial, nice guy, never making conflict, just being sleazebag.

Nobody explained to boss why iOS was always late with features, even when i complained. So i got help, 10 months later, project was unpolished but stable, codewise. Now i interview and hire a guy, age 27, who was all yeah dude no problem, and that being my first interview, i fell under his friendly appearance. I ignored a fact that he didn’t know 90% of stuff i was asking him, because he was so friendly and outgoing and we will do anything attitude.

The guy knew very little, was childish and irresponisble. He showed at work at noon. He started telling me what to do, his senior collegue who started the project. He argued about everything that i would tell him. So i spent three to four hours a day charting with him, because we were in different cities. He had two uears of experence, but he was below junior level. And he refused any of my advices for learning in free time. No, he said, thats my free time, you will not tell me what to do. Well, how do you plan on being better, i asked. He said, i learn by doing. But, since he was at his job only six hours a day, instead of eight, and since he was productive only for 2, i guess he was lazy.
He would deliver a UI he would make, without business logic, and tell it is done. Then clients would call me and ask why text fields are not saved..

This all took me month to understand. I lost time, i lost trust, and soon he was fired.

But, soon i was fired also, replaced by another two devs who i had interviewd and formed a team. I was discarded as trash, just like that. I have even worked overtime to catch up with android guys, unpaid.

Took me year to recover mentally from this.

Lessons learned: be objective when interviewing. Job is business, not friendship, trust no one, keep neutral on work. Leave honesty for someone else, honesty will be used against you. Never criticize two girls in office who disturb developers by talking about sex and dicks all the time, dressed sexy, they are girlfriends of people ranked above you. Leave code perfection for your projects.

Einstein supposedly has a quote attributed to him: "Perfection isn't achieved when there is nothing left to add, but when there is nothing left to remove."

I find that I aggressively refactor code where I can to only what is absolutely required. It does also have the knock on effect of reducing scope of bugs, when the code is smaller there's only so many places bugs can be.

Tesla claimed to have the ability to create designs in his head and only built things once he was satisfied that it worked in theory first, now it's rare I can do that, but I will use a repl to prototype or test modules in isolation before just hacking on the actual code.

Jobs, I mean, I know he didn't code but he was always insisting on designs that looked good and was generally uncompromising in his design centric view.

My friend, she was my Starbucks barista for a while but I've slowly been teaching her code and she's taught me a lot about how to teach others to code, she also happens to be my favourite student.

From a few years of programming experience, I come to know that "we cannot write perfect code."

What I mean by this is no matter how perfectly you write code, but if you have a peek on that code after about 3 months, you will be like, "I could have done a lot of things in a better way." Provided the code is atleast of 100 lines.

One of the great lessons I've learned in this career was to: "Stop rewriting up that code to perfection and start moving on to better things. Keep moving ahead. That code will be replaced and get messy again anyway."

But that doesn't mean you should write bad-designed or sloppy code.

I got inspired to make my code as closest to perfection as possible for me by my uncle. Seriously - he was real handyman.

Once he had an accident in his car (I think it was Škoda 100) because of the drunk pedestrian. The car engine was ruined, as like back of the car. He disassembled the car bolt by bolt (he was writing all the actions in his notebook). He then bought exact parts and paint (which wasn’t easy in 80’s Poland) and fixed the car alone in his garage.
Even tho everyone was telling him to give up, it will not work, etc. the car started at the first try and you couldn’t spot any damage. Even the paint on the body was matched 1:1.

This story inspires me to don’t give up and try to do my job as best as possible - even if everyone else says I can’t do it.