Omfg this fucking guy!!!!

Context:

We are going through a major refactor of some of our backend components. I was tasked with cleaning up our ML code while another guy was tasked with cleaning up the general CRUD side of the backend, let's call him DA for "dumb ass".

** At 11pm
DA: I am getting a strange error from your backend. Look:

"Invalid call: method=PUT expected=[POST]"

Me: you need to send a post request not a put request

DM: no, it's not that. I am sending the right thing

Me: ... Let me see...

* 15min ish of testing *

No, it works fine on my version, 1.1.0 what's your version?

DM: I'm on 1.1.0.

Me: send me code?

DM: *send

"request.put(..."

Me: you are sending a PUT... It's literally in the screenshot. Send a Post

DM: I am

Me: no, send a Post

DM: I don't understand, I am sending the request

Me: it's a post not a put

DM: but...

Me: it's a post not a put
Me: good night!!!!!!

"Can you work on this ticket? It's kind of urgent."

-- "OK"

"And could you please not refactor? Just get this done."

-- "Why? What's the issue?"

"The logic is complex. We should not break it."

-- "Erm, that's what the tests are for. So yes, if the need arises, I'll refactor. The tests are my guidelines if the logic breaks or not."

There's a reason we create tests. So let's not hinder code base improvements by some random fear that stuff might break.

If breaks due to refactoring, we'll fix it by adding a valid test case during and then fixing the bug.

If my refactoring does not break the tests, I'll assume the code base is stable.

If your code is untested, then we have a complete different problem.

Insecure... My laptop disk is encrypted, but I'm using a fairly weak password. 🤔

Oh, you mean psychological.

Working at a startup in crisis time. Might lose my job if the company goes under.

I'm a Tech lead, Senior Backender, DB admin, Debugger, Solutions Architect, PR reviewer.

In practice, that means zero portfolio. Truth be told, I can sniff out issues with your code, but can't code features for shit. I really just don't have the patience to actually BUILD things.

I'm pretty much the town fool who angrily yells at managers for being dumb, rolls his eyes when he finds hacky code, then disappears into his cave to repair and refactor the mess other people made.

I totally suck at interviews, unless the interviewer really loves comparing Haskell's & Rust's type systems, or something equally useless.

I'm grumpy, hedonistic and brutally straight forward. Some coworkers call me "refreshing" and "direct but reasonable", others "barely tolerable" or even "fundamentally unlikable".

I'm not sure if they actually mean it, or are just messing with me, but by noon I'm either too deep into code, or too much under influence of cognac & LSD, wearing too little clothing, having interesting conversations WITH instead of AT the coffee machine, to still care about what other humans think.

There have been moments where I coded for 72 hours straight to fix a severe issue, and I would take a bullet to save this company from going under... But there have also been days where I called my boss a "A malicious tumor, slowly infecting all departments and draining the life out of the company with his cancerous ideas" — to his face.

I count myself lucky to still have a very well paying job, where many others are struggling to pay bills or have lost their income completely.

But I realize I'm really not that easy to work with... Over time, I've recruited a team of compatible psychopaths and misfits, from a Ukranian ex-military explosives expert & brilliant DB admin to a Nigerian crossfitting gay autist devops weeb, to a tiny alcoholic French machine learning fanatic, to the paranoid "how much keef is there in my beard" architecture lead who is convinced covid-19 is linked to the disappearance of MH370 and looks like he bathes in pig manure.

So... I would really hate to ever have to look for a new employer.

I would really hate to ever lose my protective human meat shield... I mean, my "team".

I feel like, despite having worked to get my Karma deep into the red by calling people all kinds of rude things, things are really quite sweet for me.

I'm fucking terrified that this peak could be temporary, that there's a giant ravine waiting for me, to remind me that life is a ruthless bitch and that all the good things were totally undeserved.

Ah well, might as well stay in character...

*taunts fate with a raised middlefinger*

2 years into polytechnic I got my 1st big project as a subcontractor doing Symbian. No need to tell the company I presume.

Anyways, I was brought into the project just couple weeks before holiday season started. My Symbian programming experience was just the basics from school. 1st day I was crapping my pants out of anxiety. I pretty much didn't understand anything what my project manager or teammates were telling, so I just wrote EVERYTHING down on paper and recorded all the meetings to my laptop.

My job was to implement a very big end to end SDK feature. Basically from API through Symbian OS through HAL to other OS and into its subsystem. Nice job for a beginner :/

As the holidays were starting we had just drafted out the specification (I don't know how, because I didn't understand much of what was going on) and I got a clear mission from team lead. Make a working prototype of the feature during the time everybody else was on vacation.

"No problemos, I can do it" I BS'd myself and the team lead.

First 2 weeks I just read documentation, my notes and internal coding tutorials over and over again. I produced maybe couple of lines of usable code. I stayed at the office as late as I dared without seeming to obvious that I had no clue what I was doing. After the two weeks of staying late and seeing nightmares every night I had a sudden heureka moment. Code that I was reading started to make sense. Okay, still 2 weeks more until my teammates come back.

Next 2 weeks were furious coding and I got better every day. I even had time to refactor some of my earlier code so that quality was consistent.

Soooo, holidays are over and my team leader and collagues are very interested with my progress. "You did very well. Much better than expected. Prototype is working with main use case implemeted. You must have quite high competence to do this so well..."

"Well...I did have to refactor some stuff, so not 10/10"

I didn't say a word of my super late nights, anxiety and total n00biness.

Pretty much finished "like a boss". After that I was on the managers wanted list and they called me to ask if I had the time work on their projects.

Fake it, crap your pants, eat your crap and turn into diamonds and then you make it.

PS. After Symbian normal C++ and almost any other language has been a breeze to learn.

Still trying to get good.

The requirements are forever shifting, and so do the applied paradigms.

I think the first layer is learning about each paradigm.

You learn 5-10 languages/technologies, get a feeling for procedural/functional/OOP programming. You mess around with some electronics engineering, write a bit of assembly. You write an ugly GTK program, an Android todo app, check how OpenGL works. You learn about relational models, about graph databases, time series storage and key value caches. You learn about networking and protocols. You void the warranty of all the devices in your house at some point. You develop preferences for languages and systems. For certain periods of time, you even become an insufferable fanboy who claims that all databases should be replaced by MongoDB, or all applications should be written in C# -- no exceptions in your mind are possible, because you found the Perfect Thing. Temporarily.

Eventually, you get to the second layer: Instead of being a champion for a single cause, you start to see patterns of applicability.

You might have grown to prefer serverless microservice architectures driven by pub/sub event busses, but realize that some MVC framework is probably more suitable for a 5-employee company. You realize that development is not just about picking the best language and best architecture -- It's about pros and cons for every situation. You start to value consistency over hard rules. You realize that even respected books about computer science can sometimes contain lies -- or represent solutions which are only applicable to "spherical cows in a vacuum".

Then you get to the third layer: Which is about orchestrating migrations between paradigms without creating a bigger mess.

Your company started with a tiny MVC webshop written in PHP. There are now 300 employees and a few million lines of code, the framework more often gets in the way than it helps, the database is terribly strained. Big rewrite? Gradual refactor? Introduce new languages within the company or stick with what people know? Educate people about paradigms which might be more suitable, but which will feel unfamiliar? What leads to a better product, someone who is experienced with PHP, or someone just learning to use Typescript?

All that theoretical knowledge about superior paradigms won't help you now -- No clean slates! You have to build a skyscraper city to replace a swamp village while keeping the economy running, together with builders who have no clue what concrete even looks like. You might think "I'll throw my superior engineering against this, no harm done if it doesn't stick", but 9 out of 10 times that will just end in a mix of concrete rubble, corpses and mud.

I think I'm somewhere between 2 and 3.

I think I have most of the important knowledge about a wide array of languages, technologies and architectures.

I think I know how to come to a conclusion about what to use in which scenario -- most of the time.

But dealing with a giant legacy mess, transforming things into something better, without creating an ugly amalgamation of old and new systems blended together into an even bigger abomination? Nah, I don't think I'm fully there yet.

Worst of many. Had to work with someone who could be accurately described as a monkey in trousers with strategically cut fur.

Him: "I have refactored code now I have to refactor all your goddamn unit tests"
Me: "so?"
<silence>
<checks his commit>
Me: "why have you commented out every single line in all the unit tests?"
Him: "I DON'T BELIEVE WE SHOULD HAVE ANY UNIT TEST. THEY ADD TIME".
Me:"You cannot be serious. Apart from the obvious mistake in judgement why in the name of blue buggery fuck did you not delete the files? Have you not heard of source history?"
Him:"...."

I became his lead.
He left.

Don't you just love it when upper Management people that never wrote a line of code in their life tell you, the software engineer peasant, to refactor all of your projects with Inclusive Terminology?

I mean I'll do it, the company is just protecting their image and money... But I blame the sick mind that came up with this in the first place.... It's implying that all sofware engineers are somehow racist and sexist and I'm somewhat offended by that notion. Whoever started this trend should seriously burn in hell.

P. S.
Apparently "the elderly" is also non-inclusive and should be referred to as "older adult"... What the fuck?

Do you not realize that you're just disassembling words and nothing else? Also "AIDS patient" should be referred to as "person living with AIDS"... Ok? Same fucking thing? If not even worse? At least "patient" kinda invokes that professional help is given... A person living with AIDS just implies you're infected and seeking no help...

You help no one with this non-issue bullshit. All your replacements will be deemed outdated and non-inclusive in the next 5 years again... Fucking hell... Waste of time and money

The moment, when you refactor your code and it looks so clean. Priceless.

I’m adding some fucking commas.
It should be trivial, right?
They’re fucking commas. Displayed on a fucking webpage. So fucking hard.

What the fuck is this even? Specifically, what fucking looney morons can write something so fucking complicated it requires following the code path through ten fucking files to see where something gets fucking defined!?

There are seriously so fucking many layers of abstraction that I can’t even tell where the bloody fucking amount transforms from a currency into a string. I’m digging so deep in the codebase now that any change here will break countless other areas. There’s no excuse for this shit.

I have two options:
A) I convert the resulting magically conjured string into a currency again (and of course lose the actual currency, e.g. usd, peso, etc.), or

B) Refactor the code to actually pass around the currency like it’s fucking intended to be, and convert to a string only when displaying. Like it’s fucking intended to be.

Impossible decision here.

If I pick (A) I get yelled at because it’s bloody wrong. “it’s already for display” they’ll say. Except it isn’t. And on top of that, the “legendary” devs who wrote this monstrosity just assumed the currency will always be in USD. If I’m the last person to touch this, I take the blame. Doesn’t matter that “legendary Mr. Apple dev” wrote it this way. (How do I know? It’s not the first time this shit has happened.) So invariably it’ll be up to me to fix anyway.

But if I pick (B) and fix it now, I’ll get yelled at for refactoring their wonderful code, for making this into too big of a problem (again), and for taking on something that’s “just too much for me.” Assholes. My après Taco Bell bathroom experiences look and smell better than this codebase. But seriously, only those two “legendary” devs get to do any real refactoring or make any architecture decisions — despite many of them being horribly flawed. No one else is even close to qualified… and “qualified” apparently means circle jerking it in Silicon Valley with the other better-than-everyone snobs, bragging about themselves and about one another. MojoJojo. “It was terrible, but it fucking worked! It fucking worked!” And “I can’t believe <blah> wanted to fix that thing. No way, this is a piece of history!” Go fuck yourselves.

So sorry I don’t fit in your stupid club.

Oh, and as an pointed, close-at-hand example of their wonderful code? This API call I’m adding commas to (it’s only used by the frontend) uses a json instance variable to store the total, errors, displayed versions of fees/charges (yes they differ because of course they do), etc. … except that variable isn’t even defined anywhere in the class. It’s defined three. fucking. abstraction. layers. in. THREE! AND. That wonderful piece of smelly garbage they’re so proud of can situationally modify all of the other related instance variables like the various charges and fees, so I can’t just keep the original currency around, or even expect the types to remain the same. It’s global variable hell all over again.

Such fucking wonderful code.

I fucking hate this codebase and I hate this fucking company. And I fucking. hate. them.

I always wonder why people complain about php being horrible, then I actually see the code they write.

It's like complaining "I can't believe I have to use such a horrible desk" when it's littered with empty coffee cups and yesterday's lunch.

So a company I'm working at has this internal product. I just got employed and was put into that team.

"First task: refactor some of the code"

Alright, I start refactoring. Oh I may need to write a small class for this one. And then rewrite this a bit. And then rewrite that a bit. And then rewrite everything.

"Why are you rewriting most of my code?"

oh i would not have needed to do so if your code was not COMING OUT OF YOUR ASS and if all the teams had FREAKING PROPER API DOCUMENTATION

I have to refactor code from an intern. He's VERY lucky that he already left the company.

If I'd say he programms like the first human that would be very insulting to that first human.

It looks like code at first sight, but when you try to understand what he was doing to achieve his goal you get a brainfuck. Duplicate code, unused code, dumb variable names like blRszN.

He wrote unittests like "expects Exception to be thrown or Server returns Statuscode 500".
Yes, Exception, the generic one.

THESE FUCKING TESTS ARE GREEN BECAUSE YOU DID NOT ACTUALLY TEST SOMETHING.
GREEN IN THIS CONTEXT MEANS: YOUR PRODUCTION CODE IS A BIG PILE OF SHIT.

I already removed 2 bugs in a test which caused another exception than the "expected" one and the test does still not reach the actual method under test.

Dumb fucktard.

The sad thing: The fuckers who did the code reviews and let this shit pass are still here writing code.

"I'm almost done, I'll just need to add tests!"

Booom! You did it, that was a nuke going off in my head.

No, you shouldn't just need to add tests. The tests should have been written from the get go! You most likely won't cover all the cases. You won't know if adding the tests will break your feature, as you had none, as you refactor your untested mess in order to make your code testable.

When reading your mess of a test case and the painful mocking process you went through, I silently cry out into the void: "Why oh why!? All of this suffering could have been avoided!"

Since most of the time, your mocking pain boils down to not understanding what your "unit" in your "unit test" should be.

So let it be said:

- If you want to build a parser for an XML file, then just write a function / class whose *only* purpose is: parse the XML file, return a value object. That's it. Nothing more, nothing less.
- If you want to build a parser for an XML file, it MUST NOT: download a zip, extract that zip, merge all those files to one big file, parse that big file, talk to some other random APIs as a side-effect, and then return a value object.

Because then you suddenly have to mock away a http service and deal with zip files in your test cases.

The http util of your programming language will most likely work. Your unzip library will most likely work. So just assume it working. There are valid use cases where you want to make sure you acutally send a request and get a response, yet I am talking unit test here only.

In the scope of a class, keep the public methods to a reasonable minimum. As for each public method you shall at least create one test case. If you ever have the feeling "I want to test that private method" replace that statement in your head with: "I should extract that functionality to a new class where that method public. I then can create a unit test case a for that." That new service then becomes a dependency in your current service. Problem solved.

Also, mocking away dependencies should a simple process. If your mocking process fills half the screen, your test setup is overly complicated and your class is doing too much.

That's why I currently dig functional programming so much. When you build pure functions without side effects, unit tests are easy to write. Yet you can apply pure functions to OOP as well (to a degree). Embrace immutability.

Sidenote:

It's really not helpful that a lot of developers don't understand the difference between unit, functional acceptance, integration testing. Then they wonder why they can't test something easily, write overly complex test cases, until someone points out to them: No, in the scope of unit tests, we don't need to test our persistance layer. We just assume that it works. We should only test our businsess logic. You know: "Assuming that I get that response from the database, I expect that to happen." You don't need a test db, make a real query against that, in order to test that. (That still is a valid thing to do. Yet not in the scope of unit tests.)

I'm coming off a lengthy staff augmentation assignment awful enough that I feel like I need to be rehabilitated to convince myself that I even want to be a software developer.

They needed someone who does .NET. It turns out what they meant was someone to copy and paste massive amounts of code that their EA calls a "framework." Just copy and paste this entire repo, make a whole ton of tweaks that for whatever reason never make their way back into the "template," and then make a few edits for some specific functionality. And then repeat. And repeat. Over a dozen times.

The code is unbelievable. Everything is stacked into giant classes that inherit from each other. There's no dependency inversion. The classes have default constructors with a comment "for unit testing" and then the "real" code uses a different one.

It's full of projects, classes, and methods with weird names that don't do anything. The class and method names sound like they mean something but don't. So after a dozen times I tried to refactor, and the EA threw a hissy fit. Deleting dead code, reducing three levels of inheritance to a simple class, and renaming stuff to indicate what it does are all violations of "standards." I had to go back to the template and start over.

This guy actually recorded a video of himself giving developers instructions on how to copy and paste his awful code.

Then he randomly invents new "standards." A class that reads messages from a queue and processes them shouldn't process them anymore. It should read them and put them in another queue, and then we add more complication by reading from that queue. The reason? We might want to use the original queue for something else one day. I'm pretty sure rewriting working code to meet requirements no one has is as close as you can get to the opposite of Agile.

I fixed some major bugs during my refactor, and missed one the second time after I started over. So stuff actually broke in production because I took points off the board and "fixed" what worked to add back in dead code, variables that aren't used, etc.

In the process, I asked the EA how he wanted me to do this stuff, because I know that he makes up "standards" on the fly and whatever I do may or may not be what he was imagining. We had a tight deadline and I didn't really have time to guess, read his mind, get it wrong, and start over. So we scheduled an hour for him to show me what he wanted.

He said it would take fifteen minutes. He used the first fifteen insisting that he would not explain what he wanted, and besides he didn't remember how all of the code he wrote worked anyway so I would just have to spend more time studying his masterpiece and stepping through it in the debugger.

Being accountable to my team, I insisted that we needed to spend the scheduled hour on him actually explaining what he wanted. He started yelling and hung up. I had to explain to management that I could figure out how to make his "framework" work, but it would take longer and there was no guarantee that when it was done it would magically converge on whatever he was imagining. We totally blew that deadline.

When the .NET work was done, I got sucked into another part of the same project where they were writing massive 500 line SQL stored procedures that no one could understand. They would write a dozen before sending any to QA, then find out that there was a scenario or two not accounted for, and rewrite them all. And repeat. And repeat. Eventually it consisted of, one again, copying and pasting existing procedures into new ones.

At one point one dev asked me to help him test his procedure. I said sure, tell me the scenarios for which I needed to test. He didn't know. My question was the equivalent of asking, "Tell me what you think your code does," and he couldn't answer it. If the guy who wrote it doesn't know what it does right after he wrote it and you certainly can't tell by reading it, and there's dozens of these procedures, all the same but slightly different, how is anyone ever going to read them in a month or a year? What happens when someone needs to change them? What happens when someone finds another defect, and there are going to be a ton of them?

It's a nightmare. Why interview me with all sorts of questions about my dev skills if the plan is to have me copy and paste stuff and carefully avoid applying anything that I know?

The people are all nice except for their evil XEB (Xenophobe Expert Beginner) EA who has no business writing a line of code, ever, and certainly shouldn't be reviewing it.

I've tried to keep my sanity by answering stackoverflow questions once in a while and sometimes turning evil things I was forced to do into constructive blog posts to which I cannot link to preserve my anonymity. I feel like I've taken a six-month detour from software development to shovel crap. Never again. Lesson learned. Next time they're not interviewing me. I'm interviewing them. I'm a professional.

This is something I'll never forget.

I'm a senior UI engineer. I was working at a digital agency at the time and got tasked with refactoring and improving an existing interface from a well known delivery company.

I open the code and what do I find? Indentation. But not in the normal sense. The indentation only went forward, randomly returning a bunch of tabs back in the middle of the file a few times, but never returning to its initial level after closing a tag or function, both on HTML and JS.

Let that sink in for a minute and try to imagine what it does to your editor with word wrapping (1 letter columns), and without (absurd horizontal scrolling).

Using Sublime at the time, ctrl+shift+P, reindent. Everything magically falls beautifully into place. Refactor the application, clean up the code, document it, package it and send it back (zip files as they didn't want to provide version control access, yay).

The next day, we get a very angry call from the client saying that their team is completely lost. I prove to the project manager that my code is up to scratch, running fine, no errors, tested, good performance. He returns to the client and proves that it's all correct (good PM with decent tech knowledge).

The client responds with "Yeah, the code is running, but our team uses tabs for version control and now we lost all versioning!".

Bear in mind this was in 2012, git was around for 7 years then, and SVN and Mercury much longer.

I then finally understood the randomness of the tabs. The code would go a bunch of tabs back when it went back to a previous version, everything above were additions or modifications that joined seamlessly with the previous version before, with no way to know when and so on.

I immediately told the PM that was absurd, he agreed, and told the client we wouldn't be reindenting everything back for them according to the original file.

All in all, it wasn't a bad experience due to a competent PM, but it left a bad taste in my mouth to know companies have teams that are that incompetent, and that no one thought to stop and say "hey, this may cause issues down the line".

1. Identify the problem
2. Come up with a clever solution
3. Refactor half of your code
4. Watch it fail horribly because you're such an idiot it's a bloody miracle you keep breathing on your own
5. Repeat

!rant
Just started working for a new company. Super cool. Just like the last one (as far as perks), except they actually trust their devs.

Old company: Make sure your code is extensible
Devs at old company: You know it's not written in stone right?
Old company: Does that mean you can make it do this?
Devs at old company: No. That's the wrong code base

New company: I need a feature. Get it done when you can
New company devs: Well, guess I'll take some time to refactor all this stuff while I'm at it
~Some time later~
New company: Thanks, that feature works great!

No staring over shoulders, asking when it will be done. No asking why we want to refactor something. As long as work continues to flow, there are no issues. It's great!

Also, if we want to try a new tech, we just have to put together a short paper explaining why it will work better in that situation than the tech that's already in place.

Time to do a little bit of shaming:

I'm specialized in e-commerce applications, mostly based on Shopware, a german out-of-the-box online-shop. They essentially claim to be a better Magento. In December of last year I found a critical issue within the code. Products within the shop can be declared as digital wares. In that case the purchase of a product will unlock the possibility to download a designated file.

As a customer you can access your downloads within the account section. Now here's the problem: The query that fetches the unlocked downloads for a customer is hard-capped at 500 rows. So after your 500th purchase, you won't be able to access any further files you paid for. Essentially their developers thought that this limit would never be exceeded anyway and called it a day.

Personally I think this unacceptable. For the merchant this is a potential law-suit in the making. So I took the time to refactor the code and fix the issue. The corresponding pull-request was flagged as scheduled back in December. Since then there have been numerous releases and the issue is still present. Not only do I ask myself why I should ever put in time and effort to fix their code again, but I also can't believe that they just chose to ignore the issue completely. Also mind that this is not just a small or non-profit open-source project. The responsible company behind the software is a stock corporation that claims to be the market leader in Germany.

When your pm forces you to push new features out too quickly and you're slowly digging yourself into a messy hell, knowing you have to one day refactor thousands of lines of code.

Why are people complaining about debugging?
Oooh it’s so hard.
It’s so boring.
Can someone do this for me?

I honestly enjoy debugging and you should too..
if it’s not your code, you’ll get to understand the code better than the actual author. You’ll notice design improvements and that some of the code is not even needed. YOU LEARN!

If it’s your own code (I especially enjoy debugging my own code): it forces you to look at the problem from a different perspective. It makes you aware of potential other bugs your current solution might cause. Again, it makes you aware of flaws in the design. YOU LEARN!

And in either case, if it’s a tricky case, you’ll most likely stop debugging at some point, refactor the shit out of some 50-100 line methods and modulize it because the original code was undebuggable (<- made up a new word there) and continue debugging after that.

So many things I know, I know only because I spend days, sometimes even weeks debugging a piece code to find the fucking problem.

My main language is java and i wouldn’t have believed anyone who told me there’s a memory leak in my code. I mean, it’s java, right? We refactored the code and everything worked fine again. But I debugged the old version anyway and found bugs in Java (java 6.xx I believe?) which made me aware of the fact that languages have flaws as well.. GC has its flaws as well. So does docker and any other software..

Stop complaining, get on your ass and debug the shit out of your bugs instead of just writing it in a different way and being glad that it fixed the issue..

My opinion.

I just installed Opera Mini on my PSP. That alone isn't very exciting on its own, although I am stoked that my website does in fact render on a device from 2009. With the helpful guidance of a laptop from 2004 that's doing the hotspot duties for this thing.

No, what really got me stoked is that Opera still supports these old platforms, and how small they managed to make it. The .jar file for Opera Mini 4.5 is ~800kB large. There's a .jad file as well but it's negligible in size and seems to be a signature of sorts.

Let that sink in for a moment. This entire web browser is 800kB. Firefox meanwhile consistently consumes 800 MEGABYTES.. in MEMORY. So then, I went to think for a moment, how on earth did they manage to cram an entire functioning web browser in 800kB? Hell, what makes up a web browser anyway?

The answer to that question I got to is as follows. You need an engine to render the web page you receive. You need a UI to make the browser look nice. And finally you need a certificate store to know which TLS certificates to trust. And while probably difficult to make, I think it should be possible to do in 800k. Seriously, think about it. How would you go *make* a web browser? Because I've already done that in the past.

Earlier I heard that you need graphics, audio, wasm, yada yada backends too.. no. Give your head a shake. Graphics are the responsibility of the graphics driver. A web browser shouldn't dabble with those at all. Audio, you connect to PulseAudio (in Linux at least) and you're done. Hell I don't even care about ALSA or OSS here. You just connect to the stuff that does that job for you. And WebAssembly.. God I could rant about that shit all day. How about making it a native application? Not like actual Assembly is used for BIOS and low-level drivers. And that we already have a better language for the more portable stuff called C.

Seriously, think about it. Opera - a reputable browser vendor - managed to do it in 800kB on a 12 year old device. Don't go full wank on your framework shit on the comments. And don't you fucking dare to tell me that there's more to it. They did it for crying out loud. Now you take a look at your shitpile for JS code and refactor that shit already. Thank you.

Do you think refactoring code adds value?

Pick one:

1. Hard No (Only refactor when there is a dollar value associated with it, i.e new feature depends on it).
2. Somewhat Yes (Futureproof your code, anticipate easiness to build feature requested in future).
3. Yes (Developer happiness, retention and for point 2)

That feeling when you saw your code and says "I can certainly code better". Took the day to refactor and felt satisfied with the code now. I feel awesome muahahah

Typescript seems like such overkill, but then you need to refactor your code and hit a bunch of issues in production. I don't think I'll ever go without typescript again. Fuck dynamic typing, it doesn't scale

Oh, gather 'round fellow wizards of the code realm! 🧙✨ Let me regale you with the epic tale of software sorcery and the comical misadventures that come with it! 🤪🎉

So there we are, facing the dreaded Internet Explorer dragon 🐉 - an ancient, stubborn beast from the era of dial-up connections and clipart-laden websites. It breathes fire on our carefully crafted layouts, turning them into a pixelated disaster! 🔥😱

And then, the grand quest of cross-browser testing begins! 🚀🌍 One moment, your website is a shining knight in Chrome's armor, and the next, it's a jester in Safari's court. A circus of compatibility struggles! 🎪🤹

CSS, the arcane art of cascading style sheets, is our magic wand. But oh, the incantations can be treacherous! A slight misstep and your buttons start disco dancing, and your text transforms into a microscopic mystery! 🕺👀

But fear not, brave developers! We wield the enchanted sword of Stack Overflow and the shield of Git version control. We shall slay bugs and refactor with valor! ⚔️🐞

In this enchanted land, documentation is the mystical parchment, often written in the cryptic dialect of ancient monks. "This function doeth stuff, thou knoweth what I meaneth." 📜😅

And meetings, oh the meetings! 🗣️🤯 It's like a conference of babbling brooks in the forest of Jargon. "Let us discuss the velocity of the backlog!" 🌿🐇

But amidst the chaos, we code on! Armed with our emojis and a bubbling cauldron of coffee, we persist. For we are the wizards and witches of the digital age, conjuring spells in Python and brewing potions in Java. 🐍☕

Onward, magical beings of code! 🚀 May your bugs be few, and your merges conflict-free! 🙌🎩

probably every time I see my tests failing.

Each time I am writing tests I'm convincing myself "it's an investment", "spend 2 hours now to save 2 days later", "unit-tests are good".

And each time I'm chasing away ideas like "perhaps they are right, perhaps writing unit tests is a waste of time..", "this code is simple, it should ever break - why test it??", "In the 2 hours I'll spend writing those UT I could build another feature"

Yes, it is terribly annoying to write tests, especially after writing the production code (code-first approach). Why test code that you know works, right?

But after a few weeks, months or years, when the time comes to change your feature: enhance it, refactor it, build an integration with/from it, etc, I feel like a child who found a forgotten favourite candy in his pocket when I see my tests failing.

It means I did a very good job writing them
It means it was not a waste of time
it means these tests will now save me hours or days of trial-and-error change→compile→deploy→test cycles.

So yeah, whenever I see my tests fail, I feel warm and fussy inside :)

That moment when, after you've spent days trying to refactor your code to be clean and readable, you look at what you've made and you honestly feel like you actually made things worse than before.

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.

Does anyone else have experience on a team where everyone seems to be doing their own thing across the full stack/multiple systems/languages but then they're all stepping over each other, breaking other each other's code so ends up doing a lot of rework to update your code to someone else's change.

And also many wheels get reinvented in slightly different ways because no one is aware that something like ... Already exists and can be reused or refactor.... Or how to use it correctly.

Basically we're like all moving in different directions instead of in sync.

I feel maybe the team is too big and everyone is doing everything, wearing too many hats... and maybe should define roles and ownership better.

Yea sure, I'd like to refactor your fucking 1000 loc spagetti code "module" with no documentation at all...

Learn to refactor your code constantly. You are not writing code for yourself. Think about the next person who has to look at your code.

So happy about being about to convince management that we needed a large refactor, due to requirements change, and since the code architecture from the beginning had boundaries built before knowing all the requirements...

pulled the shame on us, this is a learning lesson card.. blah blah blah

Also explained we need to implement an RTOS, and make the system event driven... which then a stupid programmer said you mean interrupt driven ... and management lost their minds... ( bad memories of poorly executed interrupts in the past).... had to bring everyone back down to earth.. explained yes it’s interrupt driven, but interrupt driven properly unlike in the past (prior to me)... the fuck didn’t properly prioritize the interrupts and did WAYYY too much in the interrupts.

Explained we will be implementing interrupts along side DMA, and literally no message could be lost in normal execution.. and explained polling the old way along side no RTOS, Wastes power, CPU resources and throws timing off.

Same fucker spoke up and said how the fuck You supposed to do timing, all the timing will be further off... I said wrong, in this system .. unlike yours, this is discreet timing potential and accurate as fuck... unlike your round robin while loop of death.

Anyway they gave me 3 weeks.. and the system out performs, and is more power efficient than the older model.

The interrupting developer, now gives me way more respect...

I'm finishing up the most depressing client engagement ever. Ultimately it all traces back to their worthless Expert Beginner EA who thinks he's a genius but can't write code. I don't mean that he's not great at it. It's some of the worst I've ever seen by a person in his position.

In the time I have left here I could do so much to help them clean this stuff up so that future developers could ramp up more easily and there wouldn't be tons of duplicate code.

But I've just given up. You can't help someone who thinks their code is perfect. I don't even bother suggesting stuff any more (like don't have two methods in a class - a "real" one and one for unit testing) because he gets mad or just says that's his "pattern."

If I have a useful improvement, first he'll want me to put all new code in some new library, which is fine as an end result but you don't start with putting single-use code in a library separate from where you're using it. You work with it for a while to see what's useful, what's not, and make changes. But, you see, he just loves making more libraries and calling them "frameworks."

He tells me what he wants me to name classes, and they have nothing to do with what the classes do. When you haven't done any development yet you don't even know what classes you're going to create. You start with something but you refactor and rename. It takes a special breed of stupid to think that you start with a name.

I've even caught the dude taking classes I've committed and copying and pasting them into their own library - a library with one class.

The last time we had to figure out how to do something new I told everyone up front: Don't waste time trying to figure out how you want to solve the problem. Just ask the EA what he wants you to do. Because whatever you come up with, he's going to reject it and come up with something stupid that revolves around adding stuff to his genius framework. And whatever he says you're going to do. So just skip to that.

So that's the environment. We don't write software to meet requirements. We write it to add to the framework so that the EA can turn around and say how useful the framework is.

Except it's not. The overhead for new developers to learn how to navigate his copy-pasted code, tons of inheritance, dead methods, meaningless names, and useless wrappers around existing libraries is massive. Whatever you need to do you could do in a few hours without his framework. Or you can spend literally a month modifying his framework to do the same thing. And half the time his code collapses so that dozens of applications built on his framework go down at once.

I get frameworks. They can be useful, but only if they serve your needs, not the other way around.

I've spent months disciplining myself not to solve problems and not to use my skills.

Good luck to those of you who actually work there. I am deeply sad for the visa worker I'm handing this off to. He's a nice guy and smart. If he was stupid then he wouldn't mind dragging this anchor behind him like an ox pulling a plow. Knowing the difference just makes it harder.

Lead: alright people what are your ideas and updates for this page refactor we've been talking about.

dipshit: Alright guys, I've done a quick awesome prototype that I really like...

dipshit: *starts to speak super fast* (I catch words about function composition, clean, no side effects, speed, efficiency. Basically a string of brogrammer buzzwords.)

me: what did you mean by that? How does it work?

dipshit: *basically repeats the same drivel*

me: uh..ok I don't quite understand

everyone else looks confused.

me: ok since you've done a prototype, we take a look at it later

*** After meeting, looks at code ***

It was COMPLETE GARBAGE. He used 1,500+ lines of js in 17 files to make what was essentially a simple 2 item list.

We were looking at a way to overhaul the entire page, he "refactored" maybe perhaps 5% of the page.

There was absolutely nothing clean / functional / composable about this monstrosity. It was as if he read chapter 1 of a book on functional programming and decided he understood enough to call himself an expert.

WHY THE FUCK ARE YOU STILL HIRED?

HOW DO YOU CALL YOURSELF A DEVELOPER?

YOU ARE SELF TAUGHT, DISS PEOPLE WITH FORMAL CS/CE DEGREES AND YOU PRODUCE TRASH CODE?!

ARE YOU SO RETARDED THAT YOU DO NOT RECOGNIZE HOW STUPID YOU ARE?

Please die in a fire, along with your jock attitude and unprofessionalism. Take this worthless junk unfit to be called code with you.

I love git stash.

It's helps a lot for doing refactors to me. I guess it's not the most complex workflow, but it wasn't obvious to me when I started with git. Let me explain.

Refactors. As you start writing the first lines of a refactor, you start to notice something: you're changing too many things, your next commit is going to be huge.

That tends to be the very nature of refactors, they usually affect different parts of code.

So, there you are, with a shitload changes, and you figure "hey, I have a better idea, let me first do a smaller cohesive commit (let's call it subcommit) that changes a smaller specific thing, and then I'll continue with the upper parts of the refactor".

Good idea, but you have a shitload of changes nearly touching every file in your working copy, what do you do with these changes? You git stash them.

Let's say you stash and try to do that smaller "subcommit". What sometimes happens to me at this point is that I notice that I could do an even smaller change inside this current "subcommit". So I do the same thing, I git stash and I work on that even smaller thing.

At some point I end up `git stash pop`ing up all these levels. And it it shows that git stash is powerful for this.

* You never lose a single bit of work you did.
* Every commit is clean.
* After every commit you can run tests (automated or manual) to see shit is still working.
* If you don't like some changes that you had git stashed, you can just erase them with git reset --hard.
* If a change overlaps between a stash you're applying and the last "subcommit", then
if they differ, git shows conflicts on the files,
if they are identical, nothing happens.

with this workflow things just flow and you don't need to wipe out all your changes when doing simpler things,
and you don't need to go around creating new branches with temp commits (which results in bloated temp commits and the work of switching branches).

After you finish the refactor, you can decide to squash things with git rebase.

(Note: I don't use git stash pop, because it annoys the fuck out of me when I pop and you I get conflicts, I rather apply and drop)

ColdFusion and all ColdFusion devs should be executed. Its a god-awful software from the 90's and if you still use it you're either braindead or ignorant.

Shut up about legacy CF code too! No one cares whether or not your embeddable calendar would be hard to make in JS; fucking figure it out.

I realise that CF may make things easier in the short run, but in the long run you'll have introduced so much technical debt that you'll run crying back to JS anyways; CF is so hard to refactor and even to make flexible that you would spend less total time over an application lifecycle learning JS.

If you think : I should probably refactor this. Just do it. Especially if is your code.

I really resent people who reduce the occupation to tickets. Our world is just tickets, tickets all the way down.

"well the ticket just says this, but that's vague, so what should I do?"

You either ask for clarification, or you get creative with the blank canvas you were handed.

"well that edge case wasn't called out in the ticket's specs"

this is _why_ we do TDD - to design our code to be able to function as expected for ALL cases

"is there a ticket to refactor that?"

what?! no, it's your job to always leave code better than when you found it (within scope/reason of course)

FFS we are not hired to be code monkeys or glorified typists. There should be joy that comes from getting to be more clever than the average bear and to solve problems and improve things with your code and logic.

shit bums me out.

Tabs, or No Tabs? I did the same as this commentor 2 years ago. I can code so quick now because of this simple switch. Here's why:

(source, Laracasts.com)

Ben Smith
"I think the most beneficial tip was to do away with tabs. Although it took a while to get used to and on many occasions in the first few days I almost switched them back on, it has done wonders for my workflow.

I find it keeps my brain more engaged with the task at hand due to keeping the editor (and my mind) clutter free. Before when I had to refer to a class, I would have opened it in a new tab and then I might have left it open to make it easier to get to again. This would quickly result in a bar full of tabs and navigation around the editor would become slow and my brain would get bogged down keeping track of what was open and which tab it was in. With the removal of the tab bar I'm now able to keep only the key information in my mind and with the ability to quickly switch between recently opened files, I find I haven't lost any of the speed which I initially thought I might.

In fact this is something I have noticed in all areas of writing code, the more proficient I have become with an editor the better the code I have been writing. Any time spent actually writing your code is time in which your brain is disconnected from the problem you are trying to solve. The quicker you are able to implement your ideas in code, the smaller the disconnect becomes. For example, I have recently been learning how to do unit testing and to do so I have been rewriting an old project with tests included. The ability to so quickly refactor has meant that whereas before I might have taken 30 seconds shuffling code around, now I can spend maybe 5 seconds allowing my mind to focus much better on how best to refactor, not on the actual process of doing so."

jeff_way Mod
"Yeah - it takes a little while to get used to the idea of having no tabs. But, I wouldn't go back at this point. It's all about forcing yourself into a faster workflow. If you keep the tabs and the sidebar open, you won't use the keyboard."

Try to avoid writing code that just works because one day some of your colleagues will have to refactor all of it and changing 70 files aint something someone would enjoy doing.

I was thinking about the problems one of our clients faced with the launch of their project the other day, because things were rushed, stuff was omitted and in the end they could not meet the launch date, and I started making a list of hard lessons I learned over the years that would have helped them avoid this situation.

Feel free to add yours in the comments.

- Never deploy on Friday
- Never make infrastructure changes right before a launch
- Always have backups. Always!
- Version control is never optional
- A missed deadline is better than a failed launch
- If everything is urgent, nothing is important
- Fast and cheap, cheap and quality, quality and fast. Only one pair at a time can be achieved
- Never rush the start or the end of a project
- Stability is always better that speed
- Make technical decisions based on the needs of the project two years from now
- Code like you will be the only maintainor of the project two years from now. You probably will...
- Always test before you deploy
- You can never have too many backups (see above)
- Code without documentation is a tool without instructions
- Free or famous does not necessarily mean useful or good
- If you need multiple sentences to explain a method, you should probably refactor
- If your logic is checked beforehand, writing the code becomes way easier
- Never assume you understand a request the first time around. Always follow up and confirm

There are many more that should be on this list, but this is what came to mind now.

What does projektaquarius do when he doesn't have a working IDE? Reformat code (that I am already refactoring) to an industry standard format and prepare for the arguments that are going to come from the other group who has their own coding standard that isn't industry standard.
Already preparing for the Pascal case versus Camel case argument. Emotionally that is. Mentally the argument basically just amount to "your group didn't want to refactor the code so we did it. Live with it or you do it."

You ever sit down to code, all pumped up and ready to conquer the digital world, only to have your computer decide it's the perfect time to install updates? "Sorry, can't work right now, I'm busy optimizing your experience," it says, while you sit there twiddling your thumbs and wondering who asked for this update in the first place.

And let's talk about variable names. Who thought naming things would be the hardest part of programming? You start with `count` and `index`, but by the end of the project, you're using variables like `reallyLongVariableNameThatDescribesExactlyWhatThisThingDoes`. It's like playing a game of how many characters can you type before your fingers revolt.

Then there's the joy of debugging. You sprinkle `console.log()` like breadcrumbs through your code, trying to find where things went off the rails. Half the time, you realize you've been chasing the wrong rabbit down the wrong hole, and the other half, you discover the bug is some obscure edge case that you couldn't have predicted in a million years.

But hey, it's not all doom and gloom. There's a weird satisfaction in solving those coding puzzles, like when you finally get that algorithm to work or refactor your code into something so elegant, it feels like you've sculpted a masterpiece out of digital clay.

So here's to all the coders out there, navigating the ups and downs of curly braces and semicolons with a mix of determination and exasperation. May your code compile, your bugs be minor inconveniences, and your computer never decide to update right when you're on a coding roll!!

When your senior says he may as well stops working as I'm always refactoring his code...

Same sentence says I copy what you've done in other places so I don't see why it isn't good enough. By copy he leaves redundant code in there too.

Am I a being a douche is he just being over the top?

- He writes code and expects it to live for a long time.
- I write code and will go home and refactor my own code.

Seriously guys, how do you deal when remotely collaborating with lets say not the most motivated and competent devs?

Our scrum team got formed about 6 months ago from leftover devs of other teams, choosing a couple competent devs at the core and other devs who were kinda gotten rid of by their old teams, and after 6 months of working together I can see why.

Situation is that we are 7 devs in our team and 4 of devs are not pulling their weight. They are seniors on paper, but in reality not really.

They rarely take something complex to work on and even if they do, they make sure they take as much time as possible. Two of them are contractors who I imagine decided to treat the job as a paycheck and nothing more. There is no initiative, no push to make things better and in general attitude is to do bare minimum: only what is being asked and then delaying the hell out of tasks.

Im not exaggareting: Im talking about every possible way of dragging out the tasks: delaying communication, sitting around for a few days while not asking for new tasks to work on if they are blocked, also avoiding standups. Working for days on very basic comments in their MR's. Getting "sick" for a couple days on deadline when things get tough, so that someone else would come in, refactor and save the day. Once or twice it could be a coincidence, but nowadays I can already guess ahead of time what kind of trick they will pull now.

Our project is an android app where we have to support few different tablets, so the most recent new trick that I witnessed is devs avoiding hardware delivers, sometimes for months. Idea seems to be if you dont ping your team that you dont have hardware, then you can avoid working on related tasks with that hardware.

Worst part is that they get away with it. Our teamlead is a senior dev who is first time teamlead, doesnt code anymore and doesnt want to rock the boat. He is the type of teamlead who sets arbitrary deadlines, makes it sound that they are urgent and takes a few days off in the middle of chaos just before deadline. Restrospectives don't help at all and if I try to bring up stuff directly to him he tells me to bring it up during retrospectives. We discuss issues, rant a bit ant then continue carying on like nothing happened and nothing changes.

So little by little in the past 6 months we came to this point where 2-3 devs are carrying the weight of the team and are in a constant crunch mode, while others are allowed to slack. Its becoming ridiculous.

Problem is that this is starting to affect our morale. Only way that is left to keep my sanity right now is to pull away sometimes and also slack. Then I come back at full capacity, give my best for a couple weeks until I have to go and fix some basic leftover task that has been purposefully dragged out for 2 months and left unfinished, then I just want to scream and I know that its time to disconnect again.

So i wasted last 24 hours trying to satisfy my ego over a shitty interview and revisiting my old job's codebase and realising that i still don't like that shit. just i am 25 and have no clue where am i heading at. i am just restless, my most of the decisions in 2023 have given very bad outcomes and i am just trying doing things to feel hopeful.

context for the interview story-----
my previous job was at a b2b marketing company whose sdk was used by various startups to send notifications to their users, track analytics etc. i understood most of it and don't find it to be any major engineering marvel, but that interviewer was very interested in asking me to design a system around it.

in my 1.2 years of job there, i found the codebase to be extremely and unnecessarily verbose ( java 7) with questionable fallbacks and resistance towards change from the managers. they were always like "we can't change it otherwise a lot of our client won't use our sdk". i still wrote a lot of testcases and tried to understand the working of major features.

BTW, before you guys go on a declare me an embarrassment of an engineer who doesn't know the product's code base, let me tell you that we are talking SDKs (plural) and a service based company here. their was just one SDK with interesting, heavy lifting stuff and 9 more SDKs which were mostly wrappers and less advanced libraries. i got tasks in all of them, and 70% of my time went into maintaining those and debugging client side bugs instead of exploring the "already-stable-dont-change" code base.

so based on my vague understanding and my even more vague memory from 1 year ago, i tried to explain an overall architecture to that interviewer guy. His face was screaming the word "pathetic" from his expressions, so i thought that today i will try to decode the codebase in 12-15 hours, publish a cool article and be proud of how much i know a so called martech system design. their codebase is open sourced, so it wasn't difficult to check it out once more.
but boy oh boy i got so bored. unnecessary clases , unnecessary callbacks static calls , oof. i tried to refactor a few classes, but even after removing 70% of codebase, i was still left with 100+ classes , most of them being 3000-4000 files long. and this is your plain old java library adding just 800kb to your project.

boring , boring stuff. i would probably need 2-3 more days to get an understanding of complete project, although by then i would be again questioning my life choices , that was this a good use of my 36 hours?

what IS a correct usage of my time? i am currently super dissatisfied with my job, so want to switch. i have been here for 6 months, so probably i wouldn't be going unless i get insane money or an irresistible company offer. For this i had devised a 2 part plan to either become good at modern hot buzz stuff in my domain( the one being currently popularized by dev influenzas) or become good at dsa/leetcode/cp. i suck bad at ds/algo stuff, nor am i much motivated. so went with that hot buzz stuff.

but then this interview expected me to be a mature dev with system design knowledge... agh fuck. its festive season going on and am unable to buy any cool shirts since i am so much limited with my money from my mediocre salary and loans. and mom wants to buy a home too... yeah kill me

I'm going to confess: I am the type of developer that creates the ExcruciatinglyLongAndSpecificClassNameObject with the UtterlyDetailedExplanationMethod. It's just a thing I keep doing, despite voiced frustrations from people I've worked with. It just feels right in the mindset of self-documenting code

And while I acknowledge this isn't a flawless process, I see no other way around without losing information. I've tried alternatives, but everything feels like trading one issue for another:

- Abbreviations work as long as they are well known (XML, HTML, ...). As soon as you add your own (even if they make sense in the business context) you can bet your ass someone is going to have no idea what you're talking about. Even remembering your own shit is difficult after X months.

- Removing redundant naming seems fine until it isn't redundant anymore (like when a feature with similar traits gets added). and you can bet your ass no-one is going to refactor the existing part to specify how it differs from the newly added stuff.

- Moving details to namespaces is IMO just moving the problem and pretending it doesn't exist. Also have had folks that just auto-include namespaces in VS without looking if they need the class from namespaceA or namespaceB and then proceed to complain why it doesn't compile.

So, since I am out of ideas, I'd like to ask you folks: Is it possible to reduce class/method name lengths without losing information? Or is self-documenting code just an ideal I'm trying too hard to achieve? Or are long names not a problem at all? I'm looking forward to your answers.

How can code refactor be so stressfull that even doin' it on YOUR OWN CODE looks like taking a slow walk over broken glass? More than never: GOD BLESS THOSE WHO DAILY DEAL WITH LEGACY CODE

When you refactor your code and you wish you never did it

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.

There is a particular power move when you take someone's shit code, refactor it to make it faster, safer and more readable and then request a review from them on your PR. "See how I dunked on you, bitch. This is what superiority is about." And at the same time you can be perfectly polite with "oh you know this part of the code well, I wouldn't want to break anything there" with the "bitch" just strongly implied.

It's really sick how beginners start to code in Javascript and CSS, and their complex frameworks, without even understanding atleast the paradigm first. Googling your way up can be fine for smart ones, but as least time optimal this learning method sounds, it's as dangerous and non-productive too.
Also once project gets to a certain level, it's practically impossible to revisit and refactor old codes in front-end languages which kills the maintainability. Views?

Do you plan the application, on which you will be working, before you actually begin to write code?

I do web development and usually begin with something rough or look at designs of other developers. Like an dashboard example, when I see an image on google search that I like, I try to make something simmilar and when I have the surface I can add the functionality and improve the design.

Sometimes I have to make changes in half of the development because at the beginning there was no assumption that there will be a need for a certain functionality or I change a implemented feature to work properly, so I have to refactor something I made as a ground on which other parts will rely, although if I had planed the application in detail, maybe it wouldn't come to such refactoring.

In school we did prototypes, used to draw flowcharts and hold on a precedence diagrams that we made, but now at work when I receive an projekt I just begin to code :-D maybe this should change, how do you do it? If you plan your project, how do you do it?

What's better for finding candidates for a development role: having the candidate solve a complex whiteboard problem or have the candidate refactor some code (maybe a couple of small modules) while explaining as he/she goes through each step?

I personally feel both are good, but I think refactoring is a very much needed skill when you're dealing with the complexity of millions and millions lines of code, so being able to change your inital design to make it more readable and flexible later on is crucial. And refactoring usually goes hand and hand with having tests in place.

An interesting exercise would be to give the candidate a test suite with the corresponding code that's tested in a working state and let the candidate decide how much refactoring needs to be done. In the process the candidate would need to break and fix tests of course while changing things... it'll give a good measure of their ability to take code and change it to a "better" state of design and flexiblity.

On the other hand I do think there is a place for cliche white boarding problems because it really shows one willingness to tackle complex problems which do arise in most development jobs. Asking the questions and being persistent goes along way and can really help when you're collaborating with other developers to solve an issue at hand.

Overall I think there should be a white board problem, but I don't think that should be the deciding factor. Rather couple it with other very practical skills you should have as a developer already; among those being refactoring.

- Dealing only with your own code
- Having enough time to improve and refactor your code whenever you want
- Bug reports are detailed af and not just like "doesn't work"
- Choosing the IDE (and OS maybe, too) by yourself
- Having enough time for bugfixes, implementations
- Software is ready, when you want it, not anyone else.
- Visiting trainings or seminars to improve your skills whenever you want

Yeah, that would be pretty awesome.

Oh when you refactor the complete project structure and give for build the first time !!!
It's like you are sitting with your heart on your hand and praying to God that at least let the errors be readable(I am no genius to think I will be able to produce error free code the first time😝😝)

I need to go buy a rubber duck so it looks less like I'm talking to myself. Trying to pull out and refactor some shit functionality in a WordPress theme because the client NEEDS it. Frankly all it is doing is creating a custom post type, but they're used to the way they've been doing it and I'm stuck with dealing with it. I generally like this part of my job (my face in the code) but trying to read this huge mess of code with no standards is driving me insane.

"What in the hell are you doing here?" "Why do we have variables for $thedata, $the_data, and $theData?"
"Why are your brackets on the wrong line sometimes?"
"Why is each line in this function enclosed in it's own PHP tags rather than around the function?"

At least if I had a duck I could say I'm talking to him.

Arrgh...

I need to do a lot of refactoring and testing (%80 percent of which is integration) and ITS SO TEDIOUS!!!

Now, for anyone who says "oh, you write spaghetti code, your code shouldn't be so tedious to refactor". No. It's only tedious because it's a few thousand lines that I've been too lazy to refactor till now, and I need to go through it all.

Anybody have any advice for refactoring or testing in Go?

#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