A decade of writing code, swearing at code, rewriting the same code because “this time I’ll do it properly”, and sitting in meetings pretending I definitely understand what’s going on while quietly Googling half the words.

Here’s the stuff I wish someone had told me before I learned it the painful way:

1. There’s no such thing as perfect code
I’ve written things I was insanely proud of… only to look at them a year later and wonder who wrote that disaster. Everyone produces trash sometimes. It’s normal.

2. Untested code will betray you
I’ve been confident, very confident, and wrong every single time. If it’s not tested, assume it’s plotting against you. Bonus points if it explodes late Friday evening.

3. Communication matters more than flexing tech skills
I’ve worked with brilliant devs who created chaos because they couldn’t explain what they were doing. And I’ve worked with average devs who made entire teams move faster just by being clear. Guess who I’d hire?

4. Simple solutions age the best
My future self has cursed my past self enough times to learn this properly. Simplicity survives. Cleverness decays.

5. Over-engineering is a plague
I’ve seen people design solutions like they’re launching satellites when all we needed was a basic API. Shipping slowed, morale died, tech debt still grew. Never worth it.

6. Everything is a tradeoff
Speed vs stability, readability vs performance, sanity vs shipping on time. This job is choosing which pain you’re willing to live with.

7. Best practices aren’t universal
For every “this is the correct way”, I’ve found three exceptions. Context decides everything. Experience is basically collecting scars from learning where the rules break.

8. Shipping beats everything
Some of my cleanest, prettiest code never made it to production. Some of my ugliest hacks made customers happy instantly. Reality doesn’t care about aesthetics.

TLDR:
This job isn’t about being a code wizard. It’s about judgment, communication, managing chaos, and knowing when to stop overthinking and just ship the damn thing.

I've been working on a personal iOS project for a few years now. Part of the excitement was building everything myself. But now that I can just use Claude or something to build entire screens and functions for me, it just doesn't seem fun anymore.

And I know I could just not use AI and do it myself but I still know and understand that I COULD do all of it instantly with AI. Is there something I can do to reignite my passion?

I used to love writing code but AI has made it feel meaningless when I know it can be done for me instantly and all I have to do is a little debugging if it's even necessary.

Almost 4 years in software engineering and that's what I have learned.

1. The cost of time and engineering is more higher than that of servers.

2. Developer productivity and a technology's ecosystem are more valuable than a runtime's efficiency or the raw speed of a programming language.

3. Programming languages that are often considered slow and criticized for technical deficiencies or poor design are usually the most used and favored for building real-world software, from small to large scale, due to the flexibility they provide to engineers.

4. The choice of a tech stack, often said to depend on project requirements, is misleading and untrue; in reality, it depends on the expertise of the senior engineer and team.

5. Real agile teams don’t follow agile practices rigidly; instead, they develop their processes to maintain agility.

6. Best practices are often biased.

7. Healthy communication is key to a team’s success.

8. GitHub is the best tool for tracking and managing software development.

9. The first priority is to make it work.

10. Mastery of the basics makes you advanced.

I think daily stand-ups are horrific. No I don't want to know what Darren is doing every day at 10am. Such a waste of time and bad management.

What's yours? Could be process, estimation, standups, agile rituals, code review patterns, architecture trends, documentation rules, management habits, or anything else.

Technical debt used to mean something vague and slightly accusatory in retros, "we have a lot of debt in that service," with nobody able to say specifically what, when it was taken on, or whether it was a deliberate tradeoff or just something that happened. Half the debt conversations turned into archaeology, trying to reconstruct why a shortcut existed months after whoever took it had moved on or forgotten.

Started keeping a dead simple log, one line per deliberate shortcut, right when it happens, not retroactively:

2026-06-03 — Skipped input validation on the bulk-import endpoint.
Reason: internal tool only, low traffic, ship date mattered more.
Revisit if: exposed externally, or import volume grows past ~500/day.

That's it. Date, what got skipped, why, and the condition that should trigger revisiting it. Doesn't need to be longer than that to be useful.

What changed wasn't the amount of debt, that stayed roughly the same. What changed was that "should we deal with this now" stopped being a vague argument about how bad things felt and became a check against a condition someone had already written down. The bulk-import endpoint got flagged for revisit six months later, not because someone remembered the tradeoff, but because import volume actually crossed the number in the log, and the log made the trigger checkable instead of a gut call.

The bigger shift was in how shortcuts got taken in the first place. Writing the "revisit if" line at the moment of the decision forces you to actually think about what would make the shortcut wrong later, instead of just knowing vaguely that it's not ideal. A surprising number of shortcuts turned out to not have a clean revisit condition at all, which was itself useful information, if you can't articulate when this would become a problem, that's worth noticing before shipping it, not after.

Curious how other teams track this instead of letting it live as institutional memory that erodes the moment someone leaves. Anyone doing something similar, or is verbal/retro-based tracking still the norm most places?

Eg Linux Command line

Folks who don't speak English at all, say Russians, Chinese, French etc. How do you code? Is there a Chinese version of Python? Are you forced to code in English? Do you have your own programming languages? Generally, I want to understand how the coding experience is for non-English speakers.

Pardon my ignorance. Some basic research suggests that only documentation is translated but the actual language construct is mostly in English.

Since I need to update my status everyday, I feel that I need something significant that I did to tell every morning. If I don't have much to say I feel that they might think that I slacked off or something, which I wouldn't have and have worked the whole day. Sometimes in software dev there are issues that you face and things get delayed. I'm an experienced dev but lately Ive been feeling like daily standups are like status updates. Does anyone else feel this way?

I’ve been thinking a lot about the way new developers learn today. Most training focuses on frameworks, readability, and abstractions — all important — but something fundamental gets lost along the way.

Very few people are taught what the system itself is doing underneath their code.

Things like:

•	how CPUs schedule work

•	how threads actually share memory

•	what a race condition looks like in the wild

•	why locks exist

•	what happens in L1/L2 caches

•	how a tight loop affects the whole machine

•	what happens when ten threads hit the same data

•	why adding more hardware can slow a system down

Without that foundation, it’s easy to think performance “just happens,” or that scaling is something Kubernetes magically does for you. But the machine doesn’t care about the framework on top of it. It only cares about instructions, memory, and timing.

I’ve been a systems engineer for over 30 years. What I’m seeing now genuinely worries me.

You can’t solve performance problems by throwing more hardware at them. You solve them by understanding how things actually work and using the tools you already have wisely.

That requires developers who understand systems, not just frameworks. A single thoughtful engineer can save a company more time, money, and infrastructure than a thousand who only know how to stack layers of abstraction.

True efficiency isn’t old-school. It’s timeless.

Don't get me wrong, Jira (Task tracking) as a tool is essential to keep track of issues/features and the Agile mindset is great for developing software quickly and efficiently. But combine them together, It becomes a recipe for micro-management by Managers.

At my company, Tickets MUST be completed within the sprint, and it's constantly being monitored for performance and output. Obviously with tech, it's really hard to predict anything with full certainty, as there are lots of unknowns and complexities. But managers don't care or understand. They only care about tickets being moved from left to right.

Because of this, developers cut corners to meet deadlines, leading to low-quality software and constant burnouts.

How is it in your companies?

So now I'm responding to other people's AI agents, trying to understand all the nit picks. I'll get PR feedback like "Well copilot said this might be an issue, should we address it?"

It's slowed down the review process tremendously. I'm being asked to "fix" things that aren't solving real issues.

Don't get me wrong, I love AI as a tool for reviews. But it's a tool, not a point of authority.

My work has become incredibly boring (FE). Something that I loved has turned into boring shit. I'm forced to use AI at work, and now I don't feel like I matter at all, because it's not my code. It's not my program anymore, so I can't care about it, no matter how much I try. I've been working there for 4 years, and now I feel like if you put anyone else in my place, nothing will change. I lost all confidence in my skills. Therefore, I live in constant fear of being replaced by some vibe-code-maxer-AI-believer-bro. Maybe I tied it too much to my personality, but I can't help it, because it's been my dream since school.

I never use AI for my personal projects or personal life, but this sick feeling is eating me every day. And it's fun to write something for yourself in a different language, and it did help me for a while. But now, it stopped working... It's been a blessing to do something you love and get paid for it. I've been working shity jobs before and dreaming of it. Now, I guess I'll be just a soulless agent again, using AI to earn some money to pay my bills until I burn myself out.

I hate AI. I hate those who fell in love with it and are trying to tell me to "keep up with changing technology". I hate now something I loved...

We just received Velocity-CTD@04a788a (in a PR for an OS project I'm working on), a commit with a 30+ line message talking about vulnerabilities, mitm attacks, java's JVM, documenting custom CA certificates and java's best security practices.

The code changes? It adds a single info log, and a single debug log.

I'm done with this shit man.

That’s the post

I'm a self taught developer (JavaScript, Java, kotlin). I can imagine to learn COBOL and get all the high paying COBOL jobs no one wants to do.

But I'm sure other people much smarter than me had the same thought. So what is holding them back?

GitHub published its CTO availability update in April. Between May 2025 and April 2026, Github encountered 257 service incidents and 83 of them were capacity-related. Commit volume went from 1 billion total in all of 2025 to 275 million per week by early 2026. Claude Code alone accounts for about 2.6 million of those commits per week, up from a measly 100,000 in September 2025.

The capacity target got revised from 10x to 30x. Manual scaling interventions were required because automatic scaling wasn't built for burst agentic load.

The part that's hard to model is human developers have a rhythm. Pushes cluster during business hours, drop off at night, spike around sprint deadlines. AI coding agents commit, open PRs, trigger CI pipelines, and hit APIs continuously, in parallel, at whatever rate the underlying model runs. The traffic shape looks nothing like what GitHub's capacity planning was built around.

83 of the 257 incidents were capacity failures. The signals existed but the model for what "normal" looks like was just wrong.

The thing I saw lacking with 257 incidents in 12 months on a platform simultaneously being rearchitected and scaled 30x, SRE teams are spending as much time reconstructing what happened as they are fixing it. Most post-mortem formats were designed for human-speed incidents on stable platforms.

Before you downvote me, hear me out.

And yes, I met few good managers, but it was roughly 10% (max 20%). Rest of them just somehow goes from one meeting to another, shows some graphs, speak some buzzwords and - what is most ridiculous - it works.

15 years ago Agile started to be a thing. One could have become a manager if was able to run scrum ceremonies or introduce maximum work-in-progress items in kanban.

In meantime era of S.M.A.R.T. goals appeared. Short googling and you can find tons of examples when this technique doesn't work.

Then era of code coverage and SonarCloud kicked in - teams/engineers were managed by this "objective" numbers. No single manager I know ever checked if the code coverage is achieved by sensible tests. Only final number matterd (80%? Woohoo!), and number of issues reported by sonar (Going down? Awesome!)

I'm not even mentioning worst things like measuring teams by lines of code, tickets closed, etc.

Elon Musk once said you can't be cavalry captain if you can't ride a horse. (You can dislike Elone, but this statement is so much true).

Every single project I've seen in my life ended as an unmaintainable mess if there was no competent tech lead. I've seen no manager who was able to turn bad project into good one - best they did was somehow keep it alive long enough until they moved on, or engineers were burnt out.

What I see, managers in IT:

• see some numbers and arbitrary iterpret it

• cover problems, and never fix root causes

• sells their ideas beautifully

• creat road maps which are NEVER ever follow (2nd week and new requirements come)

Not sure if that's the case with every single industry, or just SWE has such bad luck?

In other fields its not really as "difficult" as programming. You attend meetings, talk with people, work long hours on a power point or excel, but its never "I dont know how to solve this".

With software, what matters is that very technical line of code you write. Either it works and it checks green, or it doesnt. If you cant solve it, sucks to be you. Also your work is being daily evaluated by your peers. If its subpar code, people are gonna see it. Every day, evaluated, put under the microscope. Not finished within the estimated time limit because yorue simply not good enough? Sucks for you

I love this field of work, but holy shit is it scary. Anyone else feel this?

Actually it happened in June of 2025, but the process has completed recently, though. After Apple had announced the support of OCI-compatible containers in the June '25 it took a year to complete development and implement full support of continers. Apple had published 1.0 version of own container manager (https://github.com/apple/container), and now Linux has became the first standard operating system. Now Linux is a part of any major platform: Windows, MacOS, BSD and Linux itself. Knowledge of Linux is now part of learning for any of these systems, at least for developers. And now you can rely on Linux based containers running everywhere. What it is if not a win!?

What's also interesting. Linux can run other Linux distros and with this Alpine Linux could become the most popular version of Linux in the World

It's the biggest win for the whole open-source software and I believe it should get into history books of technological progress

It’s not even the bugs that drain me. It's:

Jira ticket —> Slack ping —> Vscode —> Notion doc —> AI tool (copilot/blackbox/cursor) —> back to Jira. By the time I loop back, I’ve forgotten why I started. If anyone's found a way to actually stay in flow, tell us pls.

While in tech we can work remotely, demand is what drives our work. My company just laid off 20 people and the rest took 20% pay cut indefinitely. Every single client put every single project on hold.

Good luck to everyone out there! Stay safe and healthy!

I am senior backend Java developer. I cry for the days when in university or at home I could program something using plain Java or C++. It was a lot of work but I felt productive.

Nowadays I have to learn a new framework, a library, a build tool, a NoSQL DB, a CICD framework every 6-12 months. There is no time to really learn any of these very complex tools and become productive with them. Because it all starts over every 6-12 months.

A quick example would be "we need to use a MQ in our architecture, we choose one, e.g. ActiveMQ (Artemis)." (It could be any other MQ) It has a 600 pages long documentation (which is great btw), and we are expected to use and operate it correctly, efficiently etc. and do similarly for everything else in our toolbox.

My routine often helps but often doesn't: "it worked this way in Spring, must be working similar in Micronaut, nope those guys did it totally differently".

It's not that I don't like to learn, it's the draining task of wrestling with the framework every once in a while instead of delivering a solution to a problem and move to the next feature.

My boss (non-programmer) used AI and did lots of complicated merges where the history looks like spaghetti and there is no making sense of it.

Now I would say that one of my own branches is the best candidate for a new main branch. Yes, my boss messed up the main branch too.

So what would be the workflow to just have a new "main". Do we just rename the branches and call it a day? Or is there a different recommended process?

First some background. When I was 12 years old my dad introduced me to coding, and I immediately fell in love. It allowed me to be creative while simultaneously feeling like solving a logic puzzle. Fun! Fast forward two decades, and I am working at a consultant firm. Part of the time I am helping our customers, most of which is not software development. The other part is developing and designing a new software that we will eventually introduce to our customers to better solve their problems. I have been working on this software for 1.5 years, and it's mostly just me working on it so far. It has felt very rewarding to develop, I've learned a lot during this time and it has also made me a very important person in the company.

A lot has happened in 1.5 years. When I started, I experimented a bit with letting LLMs generate code snippets, which worked fine, but anything more complicated and it broke down. At this point in time, trying to let the AI write the code by itself would've been catastrophic. Sure, there were plenty of "AI influencers" hyping AI to the sky, but at the same time, plenty of well known people calling them out. But now, the tone has shifted completely. The people who were very skeptical at first seem to have turned around (for the most part). I know people in real life that are vibe-coding things that actually work. People have been screaming about 10x productivity for a while now, but maybe we're actually getting to that point soon?

So if using AI agents to write the code for you is the new path forward, I would be a fool to not do it, right? My problem is that it takes away what got me into software in the first place, writing the code, solving problems and learning new things. These are things I am good at. Being a manager to a group of AI agents is something I am not good at, nor interested in doing. Telling someone else to do something does not give the same satisfaction as doing it yourself.

At the same time, since this is what I do at work, ignoring a huge productivity boost because it doesn't feel as fun and rewarding can not really be justified either. Even if I am overestimating current models, they're likely going to keep getting better. I could probably pivot to doing more consultant work and have someone else in the company take over. Still, it feels sad to put software development and coding behind me.

I don't really know why I wrote all of this, maybe I just wanted to get it off my chest. Does anyone else feel the same way?

tl;dr: Feeling like AI agents are going to take away the joy of developing software. Not sure how to proceed.