So, there's this big company in Poland with its name starting with C and having CEO famous for saying that every software developer can be replaced with a finite number of college students.

They recently lost a HUGE government contract and so stories of people working there came to light. My two personal favourites:

1. A tester who has been fired for finding too many bugs and mistakes in their product. He was also told that bugs are to be found by clients on production, not in-house.

2. A programmer who was yelled at by his team leader for "wasting time" on code reviews instead of typing the code. He was also told he hadn't been hired to criticise other people code.

God, I'm so grateful I don't work there.

“Don’t learn multiple languages at the same time”

Ignored that. Suddently I understood why he said that. Mixed both languages. In holiday rechecked it and it was ok.

Sometimes mistakes can lead to good things. After relearning I understood it much better.

“Don’t learn things by head” was another one. Because that’s useless. If you want to learn a language, try to understand it.
I fully agree with that. I started that way too learning what x did what y did, ... But after a few I found out this was inutile. Since then, I only have problems with Git

Another one. At release of Swift, my code was written in Obj-C. But I would like to adopt Swift. This was in my first year of iOS development, if I can even call it development. I used these things called “Converters”. But 3/4 was wrong and caused bugs. But the Issues in swift could handle that for me. After some time one told me “Stop doing that. Try to write it yourself.”

One of the last ones: “Try to contribute to open source software, instead of creating your own version of it. You won’t reinvent the wheel right? This could also be usefull for other users.”

Next: “If something doesn’t work the first time, don’t give up. Create Backups” As I did that multiple times and simply deleted the source files. By once I had a problem no iOS project worked. Didn’t found why. I was about to delete my Mac. Because of Apple’s WWDR certificate. Since then I started Git. Git is a new way of living.

Reaching the end: “We are developers. Not designers. We can’t do both. If a client asks for another design because they don’t like the current one tell them to hire one” - Remebers me one of my previous rants about the PDF “design”

Last one: “Clients suck. They will always complain. They need a new function. They don’t need that... And after that they wont bill ya for that. Because they think it’s no work.”

Sorry, forgot this one: “Always add backdoors. Many times clients wont pay and resell it or reuse it. With backdoors you can prohibit that.”

I think these are all things I loved they said to me. Probably forgot some.

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 :)

People:
- human brain is imperfect, makes too many mistakes
- let's make a computer that could perform perfect precise calculations
- computers are imperfect, require a set of clearly predefined rules [by human] to operate
- let's create a computer that behaves like human brain - an AI
- ...

Guess what's gonna be the next entry :)

I propose that the study of Rust and therefore the application of said programming language and all of the technology that compromises it should be made because the language is actually really fucking good. Reading and studying how it manages to manipulate and otherwise use memory without a garbage collector is something to be admired, illuminating in its own accord.

BUT going for it because it is a "beTter C++" should not constitute a basis for it's study.

Let me expand through anecdotal evidence, which is really not to be taken seriously, but at the same time what I am using for my reasoning behind this, please feel free to correct me if I am wrong, for I am a software engineer yes, I do have academic training through a B.S in Computer Science yes, BUT my professional life has been solely dedicated to web development, which admittedly I do not go on about technical details of it with you all because: I am not allowed to(1) and (2)it is better for me to bitch and shit over other petty development related details.

Anecdotal and otherwise non statistically supported evidence: I have seen many motherfuckers doing shit in both C and C++ that ADMIT not covering their mistakes through the use of a debugger. Mostly because (A) using a debugger and proper IDE is for pendejos and debugging is for putos GDB is too hard and the VS IDE is waaaaaa "I onlLy NeeD Vim" and (B) "If an error would have registered then it would not have compiled no?", thus giving me the idea that the most common occurrences of issues through the use of the C father/son languages come from user error, non formal training in the language and a nice cusp of "fuck it it runs" while leaving all sorts of issues that come from manipulating the realm of the Gods "memory".
EVERY manual, book, coming all the way back to the K&C book talks about memory and the way in which developers of these 2 languages are able to manipulate and work on it. EVERY new standard of the ISO implementation of these languages deals, through community effort or standard documentation about the new items excised through features concerning MODERN (meaning, no, the shit you learned 20 years ago won't fucking cut it) will not cut it.

THUS if your ass is not constantly checking what the scalpel of electrical/circuitry/computational representation of algorithms CONDONES in what you are doing then YOU are the fucking problem.

Rust is thus no different from the original ideas of the developers behind Go when stating that their developers are not efficient enough to deal with X language, Rust protects you, because it knows that you are a fucking moron, so the compiler, advanced, and well made as it is, will give you warnings of your own idiotic tendencies, which would not have been required have you not been.....well....a fucking idiot.

Rust is a good language, but I feel one that came out from the necessity of people writing system level software as a bunch of fucking morons.
This speaks a lot more of our academic endeavors and current documentation than anything else. But to me DEALING with the idea of adapting Rust as a better C++ should come from a different point of view.

Do I agree with Linus's point of view of C++? fuck no, I do not, he is a kernel engineer, a damn good one at that regardless of what Dr. Tanenbaum believes(ed) but not everyone writes kernels, and sometimes that everyone requires OOP and additions to the language that they use. Else I would be a fucking moron for dabbling in the dictionary of languages that I use professionally.
BUT in terms of C++ being unsafe and unsecured and a horrible alternative to Rust I personaly do not believe so. I see it as a powerful white canvas, in which you are able to paint software to the best of your ability WHICH then requires thorough scrutiny from the entire team. NOT a quick replacement for something that protects your from your own stupidity BY impending the use of what are otherwise unknown "safe" features.

To be clear: I am not diminishing Rust as the powerhouse of a language that it is, myself I am quite invested in the language. But instead do not feel the reason/need before articles claiming it as the C++ killer.

I am currently heavily invested in C++ since I am trying a lot of different things for a lot of projects, and have been able to discern multiple pain points and unsafe features. Mainly the reason for this is documentation (your mother knows C++) and tooling, ide support, debugging operations, plethora of resources come from it and I have been able to push out to my secret project a lot of good dealings. WHICH I will eventually replicate with Rust to see the main differences.

Online articles stating that one will delimit or otherwise kill the other is well....wrong to me. And not the proper approach.

Anyways, I like big tits and small waists.

So we had this legacy Objective-C codebase for a mobile app that was actually pretty good: I'd inherited the codebase and spent the past several years gradually improving it and I was actually quite proud of the work I put into it. So of course management decides to scrap it (with NO consultation from the engineers) and outsource a complete rewrite of the app in C# for Windows Universal.

Let me tell you. That code was without a doubt and without exaggeration the *worst* code I've seen in my close to 30 years of experience as a developer. I mean they broke every rule in the book, I'm talking rookie mistakes. Copypasta everywhere, no consistent separation of concerns, and yet way too many layers. Unnecessary layers. Layers for the sake of layers. There was en entire abstraction layer complete with a replicated version of every single data class *just* to map properties in pascal case to the same property in camel case. Adding a new field to a payload in the API amounted to hours of work and about eight different files that needed to be modified. It was a complete nightmare. This was supposed to be a thin client, yet it had a complete client-side Sqlite database with its own custom schema (oh and of course a layer for that!) completely unrelated to the serverside schema, just for kicks. The project was broken up into about eight or nine different subprojects, each having their own specific dependencies on various of the other subprojects in such a tightly-knit way that it made gradual refactoring almost impossible. This architecture was so impressively bad, it was actually self-preserving!

Suffice it to say it was a complete nightmare, and was one of the main reasons I ended up leaving that company. So just sayin', legacy code isn't always bad. :)

A bug is born
... and it's sneaky and slimy. Mr. Senior-been-doing-it-for-ears commits some half-assed shitty code, blames failed tests on availability of CI licenses. I decided to check what's causing this shit nevertheless, turns out he forgot to flag parts of the code consistently using his new compiler defines, and some parts would get compiled while others needed wouldn't .. Not a big deal, we all make mistakes, but he rushes to Teams chat directing a message to me (after some earlier non-sensible argument about merits of cherry picking vs re-base):
Now all tests pass, except ones that need CI license. The PR is done, you can use your preferred way to take my changes.

So after I spot those missing checks causing the tests to fail, as well as another bug in yet another test case, and yet another disastrous memory related bug, which weren't detected by the tests of course .. I ponder my options .. especially based on our history .. if I say anything he will get offended, or at best the PR will get delayed while he is in denial arguing back even longer and dependent tasks will get delayed and the rest of the team will be forced to watch this show in agony, he also just created a bottleneck putting so many things at stake in one PR ..

I am in a pickle here .. should I just put review comments and risk opening a can of worms, or should I just mention the very obvious bugs, or even should I do nothing .. I end up reaching for the PM and explained the situation. In complete denial, he still believes it's a license problem and goes on ranting about how another project suffering the same fate .. bla bla bla chipset ... bla bla bla project .. bla bla bla back in whatever team .. then only when I started telling him:
These issues are even spotted by "Bob" earlier, since for some reason you just dismissed whatever I just said ..
("Bob" is another more sane senior developer in the team, and speaks the same language as the PM)
Only now I get his attention! He then starts going through the issues with me (for some reason he thinks he is technical enough to get them) .. He now to some extent believes the first few obvious bugs .. now the more disastrous bug he is having really hard time wrapping his head around it .. Then the desperate I became, I suggest let's just get this PR merged for the sake of the other tasks after may be fixing the obvious issues and meanwhile we create another task to fix the bug later .. here he chips in:
You know what, that memory bug seems like a corner case, if it won't cause issues down the road after merging let's see if we need even to open an internal fix or defect for it later. Only customers can report bugs.

I am in awe how low the bar can get, I try again and suggest let's at least leave a comment for the next poor soul running into that bug so they won't be banging their heads in the wall 2hrs straight trying to figure out why store X isn't there unless you call something last or never call it or shit like that (the sneaky slimy nature of that memory bug) .. He even dismissed that and rather went on saying (almost literally again): It is just that Mr. Senior had to rush things and communication can be problematic sometimes .. (bla bla bla) back in "Sunken Ship Co." days, we had a team from open source community .. then he makes a very weird statement:
Stuff like what Richard Stallman writes in Linux kernel code reviews can offend people ..

Feeling too grossed and having weird taste in my mouth I only get in a bad hangover day, all sorts of swear words and profanity running in my head like a wild hungry squirrel on hot asphalt chasing a leaky chestnut transport ... I tell him whatever floats your boat but I just feel really sorry for whoever might have to deal with this bug in the future ..

I just witnessed the team giving birth to a sneaky slimy bug .. heard it screaming and saw it kicking .. and I might live enough to see it a grown up having a feast with other bug buddies in this stinky swamp of Uruk-hai piss and Orcs feces.

*cracks knuckles*

Boy was I happy to see this when I opened devRant up.

So for starters, more group projects are necessary. Many reasons why. To begin with, it allows for more complex programs than getting some input and printing some shit out. It also develops interpersonal skills (I hate people too, but when you go out to look for work you'll be with them, so better get used to it soon). If a platform like GitHub is used, it's easy to track who did what, and see what each person in the group did, so it should be fairly easy to discourage lazy asses.

Beyond that, stop giving us half completed assignments and asking us to fill in a function/method. Yes, it will take longer. But one doesn't learn to program by doing the minimum required work, you've got to crash and burn a lot in order to git gud. So ffs, let us do all the work. We're like AI, we learn through reinforcement learning.

Stop giving us a spec to follow. We'll do plenty of that in the future, right now we need to make mistakes, not be held by the hand all the way. Let us do dumb shit so you can fail us and tell us our code is repulsive, and this other way was better. Explain why. That's how people learn, not by telling us what each function should return, what can and can't be used, etc. And if you can't come up with a scenario in which what you're teaching is useful, then maybe you're not teaching us the right material.

I'll leave it at that for today... But I'll be back 😈

This new job has more work than I can possibly complete in a day, week, or month. Deadlines pile up and I’m thoroughly exhausted all weekend. My mind feels lethargic and dull. People around me seem to be getting stuff done and I feel like I’m making too many mistakes and holding everyone back. Not sure I can stick with this job for the long haul to retirement. But freelancing absolutely sucks because nobody wants to pay you enough to feed yourself and it doesn’t scale to a full time salary for me. I simply don’t have the mental capacity to do the equivalent of four peoples’ jobs to design, code, QA, launch, and do all the digital marketing, advertising, writing, and maintenance for enough sites to make up my salary.

There's this online game I like to play, basically you can play against 2 or 3 other people / robots. It's been free to play for almost a decade, but recently they decided to limit how many games you can play each day, unless you buy membership. It's not much, about 2€ per month, so I bought it to support the devs, they're doing good work and they're not spamming players with ads, so they need to get money for those servers somewhere.

But now I kinda regret it; there used to be a whole lot of casual players online all the time, now casual players reach their daily limit and when I log on in the evening, there are almost exclusively paying members left, giving you absolute shit for the tiniest mistakes.

On a completely unrelated note, what casual / relaxing multiplayer games would you recommend that don't require too much thinking & long-term skills?

So I now bought an iphone 6 again for development and tried just for fun to make it a daily driver and it feels really limited, especially because apparently theres no jailbreak yet for 11.2.5. (I feel near everything could be solved as soon as cydia etc. get fully released to the alibaba jailbreak)

I didnt even remember, that it doesnt have any option to have haptic feedback when typing, such a basic feature has to be jailbroken..? I thought I remembered that it had it, last time I had one - did they remove such a basic feature?

Also the fingerprint reader is really weird compared to other phones from the same year, first getting it to actually fill all fingerprint lines without saying "try again" or it trolling you and vibrating as if it recognized your finger, but actually didnt (really frustrating when its the last 2 lines...) - is a real challenge, might be that I have some mutant fingerprints, but when I asked my s/o to try it out, it also failed most of the times, so you have to position your finger in a very specific position for it to work, even if you add the max amount of 5 fingerprints.

Most ads on iphones feel HORRIBLE, the amount of lag some can add is incredible, wait till it loaded or youre fucked and besides using some shady adblocker vpn, theres no way to block them, without again - a jailbreak.

Another feature that I used many times on my android phone, is controlling it from the desktop, connect it via usb and then just use it for demonstration purposes on a projector or to instruct how things work - theres no such function without a jailbreak, even if you use osx..

Then theres the feature, that instead of just setting your cursor to a specific location, you have to hold and it zooms in, not sure if I just got too used to the android way of doing it, but I can see myself making less mistakes of where I positioned it with the ios way.

The hardware mute switch feels like a great feature, its just sometimes weird, so if you were inside an app that was playing sound and you mute it, it still plays it until you either close and open that app or just change to another one temporarily, so its not an actual hardware switch as I usually thought, more like a request to mute the phone.

The cable that comes with it is too thin, I am afraid to even unwind it, as it would probably break, so I had to get another one.

Please don't turn this into a shitfest from any of the fanboys, I really just wanted to share my image of finally being able to try it first hand again.

- have/share an agenda as soon as possible
- each talking point should identify a problem. Make a list of strategic questions answers to which would make it perfectly clear what and by whom has to be done to resolve them.
- plan meeting duration according to the list of questions. Make sure you meeting room reservation gives you enough time
- take notes
- be prepared for a need for another meeting(s), if during that meeting it comes clear that:
> more/other people need to be engaged
> some things are not clear and need more investigation before going further
> you have run out of time
> there are other problems tgat need to be worked out and it might cobsume too much time to do this in a current meeting
- do not turn the meeting into a chat. It's counter-productive, tiring to the listeners and a waste of time
- do not try to cover many topics. The less, the better. Unless they are very tightly coupled.
- do not invite people you do not need or there is a very slim chance you will need.
- only schedule meetings when the situation needs to be DISCUSSED among multiple parties
- that being said, do not schedule meetings when it's more convenient to communicate otherwise, like email, chat, etc.
- after the meeting make a summary and send it our to all the participants. They might reply and clarify if you have misunderstood smth or missed some important point.
- during the meeting assign tasks to each other. Verbally. Make notes. After the meeting reflect them in jira, rally, wtv.
- while assigning tasks nake sure the assignees have no blockers to work on them and make sure they understand what, when and how should be done. Some tasks might be dependedt on each other, work the sequence out.
- while assigning tasks ask "for ETAs. They might be as silly as 1-hour-to-2-weeks, but they still let you know what to expect.
- offer your assistance to the task assignees if they need any while working on their tasks

- work on your language, grammar, syntax, etc. Reading texts with typos/mistakes is repelling

- be a leader, an authority everyone is looking up to. Not a boss.
- avoid saying NOs. Be more of a "do we really need this; can we do this some other way/time; I can't promise anythibg but I'll see what I can do about it" kind of person.

Good code is a lie imho.

When you see a project as code, there are 3 variables in most cases:

- time
- people / human resources
- rules

Every variable plays a certain role in how the code (project) evolves.

Time - two different forms: when certain parts of code are either changed in a high frequency or a very low frequency, it's a bad omen.

Too high - somehow this area seems to be relentless. Be it features, regressions or bugs - it takes usually in larger code bases 3 - 4 weeks till all code pathes were triggered.

Too low - it can be a good sign. But it should be on the radar imho. Code that never changes should be reviewed at an - depending on size of codebase - max. yearly audit. Git / VCS is very helpful here.
Why? Mostly because the chances are very high that the code was once written for a completely different requirement set. Hence the audit - check if this code still is doing the right job or if you have a ticking time bomb that needs to be defused.

People
If a project has only person working on it, it most certainly isn't verified by another person. Meaning that only one person worked on it - I'd say it's pretty bad to bad, as no discussion / review / verification was done. The author did the best he / she could do, but maybe another person would have had an better idea?

Too many people working on one thing is only bad when there are no rules ;)

Rules. There are two different kind of rules.

Styling / Organisation / Dokumentation - everything that has not much to do with coding itself. These should be enforced at a certain point, otherwise the code will become a hot glued mess noone wants to work on.

Coding itself. This is a very critical thing.

Do: Forbid things that are known to be problematic in the programming language itself. Eg. usage of variables in variables, reflection, deprecated features.

Do: Define a feature set for each language. Feature set not meaning every feature you want to use! Rather a fixed minimum version every developer must use and - in case of library / module / plugin support - which additional extras are supported.

Every extra costs. Most developers don't want to realize this... And a code base that evolves over time should have minimal dependencies. Every new version of an extra can have bugs, breakages, incompabilties and so on.

Don't: don't specify a way of coding. Most coding guidelines are horrific copy pastures from some books some smart people wrote who have no fucking clue what you're doing and why.

If you don't know how to operate on people, standing in an OR and doing what a book told you to do would end in dead person pretty sure. Same for code.

Learn from mistakes and experience, respect knowledge from other persons, but always reflect on wether this makes sense at this specific area of code.

There are very few things which are applicable to a large codebase on a global level. Even DRY / SOLID and what ever you can come up with can be at a certain point completely wrong.

Good code is a lie - because it can only exist at a certain point of time.

A codebase should be a living thing - when certain parts rot, other parts will be affected too.

The reason for the length of the comment was to give some hints on what my principles are that code stays in an "okayish" state, but good is a very rare state

I got a REALLY nice compliment from my dev team today. But first, the setup...

Tuesday night, I pushed some changes before I left that totally borked the build today when my team pulled changes (this is an off-shore team, so we more or less work opposite hours). Fortunately, my team dealt with it easy enough since (a) it was pretty obvious what happened, and (b) my commit message had enough information to help them know for sure, and they just reverted one file and were good to go for the day (they didn't fix the problem, left that for me to do, which is proper).

It was an absolutely stupid, careless mistake: I somehow copied the contents of a JS file into a JSP and pushed it. Just a simple case of too many tabs open at once and too many interruptions while I'm trying to code (which is typical most days, unfortunately, but this day it had an impact other than just slowing me down).

But, those are the reasons it happened, they aren't excuses. It was carelessness, plain and simple.

So, once I fixed it, I sent a note to the team explaining it. It basically said "Look, that was a dumb, careless mistake on my part, my bad, sorry for the inconvenience, it's fixed now."

I had a message waiting for me in my inbox this morning that said how I'm an inspiration because despite all my knowledge and experience, despite being a long-time lead, they (a) appreciate the fact that I'm human and still make mistakes, and (b) I stand up and take responsibility when it happens and then do what's necessary to reverse the mistake.

That made my day :)

To me, it's just the right way to be (I credit my parents 100%), never occurs to me to do otherwise, but the truth is not everyone can say the same. Some people are insecure and play the CYA game right away, every time. Some people act like they never make mistakes in the first place.

I don't care if you're an experienced dev or a junior, always take responsibility for your actions, especially your mistakes. Don't try and bullshit your way out of them. Sure, it's fine to explain why it happened if there were factors beyond your control, but at the end of the day, own up to them, apologize where necessary, and then put in the effort to make it right. Most people have no problem with people who make mistakes every so often - everyone does, whether everyone admits to it or not - but those who try and shirk responsibility don't last long in this or any endeavor (you know, putting aside the professional bullshitters who build their careers around it... that's not most people, thankfully).

My (almost) everyday work is a total fail. I hate my coworker. He's making decisions too fast, based on emotions, not learning on his mistakes, making many false assumptions and so on... Fuck, I hate working with him and I'm sick when I need to explain any advanced concept to him

Warning: /Stage[Job]/Developer/Exec[do-work]: Skipping because of failed dependencies :: Sleep

Best path depends on where you are in life and what you can afford.

Used to be the case that formal college/uni for K-12 graduates was a great path, provided you had the tenacity to stick with the program.

I had almost dropped out of my bachelor of programming systems 4year programme because it was too strict for my lazy ass, but it was totally on me to not be giving it my best.

Now, fast forward to today's age we have a lot of accelerated paths a person can take to get the foot in - bootcamps are successful option for many, but you need to immerse yourself and give it your all to start getting a feel for software dev mindset.

Self-teaching is and was a viable option, but you run a risk of embeddding a lot of potential mistakes to your thinking/process which can make it hard to work in real scenarios with other people.

In short, college and bootcamps are still king, I think

Every day my company reminds us that we must be a team. My coworker is near to degree in software eng, but have some difficults. This person made many mistakes in the past, but it's still with us. He need an help, but everyone is too busy!!!
Fuck you motherfuckers!!! I help him and after graduation, "I'll slap on the face"! But now, I cannot leave him alone. When is so close to graduation...

BASTARDS MOTHERFUCKERS!