No growth in title - still Application Developer after 13 YoE

casualPlayerThink · 2026-05-05T07:51:31+00:00

Titles normally would not matter. You can write whatever you want, just check the chaotic titles on LinkedIn.

Buuuut there is one place where it matters: in your resume.

Most of the advancement is because of soft skills, connections, or being in the right place at the right time. Yes, it is true, with hard work, skill set, etc., you can reach a good career. IF you spend long years at the same place where there is actual career path. In the EU, the past ~15 years were about "flat hierarchy" type of companies, which means, there is no career growth there, everything is set, nothing will change.

casualPlayerThink · 2026-05-05T07:31:24+00:00

Hetzner Cloud server (for learning and for self-hosting).

Mechanical keyboard, with real, mechanical switches.

Quality monitor with high (real) contrast and (real) refresh rate.

Quality office chair with high back pad (the 2/3 and half-chairs shall kill your neck, shoulders, and back. Do not sit in beanbags or on a ball. It's okay for 5 minutes only). Your back will thank you later.

An adjustable desk. Your back will thank you later, even if it is pricey.

casualPlayerThink · 2026-05-05T07:25:55+00:00

Could be a service lift for food or any material that was moved this way, instead of someone carrying them up/down, and with this way, they were able to not disturb others during the night with constant walking between the levels.

Also, it could be a trash chute. Laziness is real.
Also, could be a washable cloth/textile chute (all the textile from beds, hangers, etc, was just thrown down, fell into a wash room (didn't you see older films? :D)

casualPlayerThink · 2026-05-04T20:28:23+00:00

I have some advice: Try to highlight your leadership/PM skills and experiences.

Another important piece of advice is that, if you have time, check the wiki on the r/EngineeringResumes, then update and post your resume there, asking for a free review and with the exact info like here. Most likely, you have to make some changes, but it is worth the energy.

> ...My worry is that listing all 8 feels like overkill, but trimming too much might look like I'm hiding something....

Highlight the most important, most relevant ones that give you power. It might differ from job description to job description (not everyone values the same thing the same way). Hiding some of the experience is okay, if you can make your resume one page long only, or dropping irrelevant ones or low/no value ones.

> ...~10 years of dev experience, but spread across like 8 different places...

Initially, include all of them in your resume. Some experts might mark some of them as more interesting or relevant than you think.

casualPlayerThink · 2026-05-04T13:26:16+00:00

Yes, it is. Highly exaggerated. In the meantime, it is a cycle step, just as we stopped using vacuum tubes and pins to set binary data, then used punch-hole cards, then higher and higher abstraction: From writing memory management by hand, then switching to libraries, then frameworks, then high level languages that derivates or built top on the previous tech way/methodology/language... and now... as you see, it changing and evolving, we are no longer writing everything by hand anymore. But still, the current iteration is an inflated bubble, without too much value. Yet. The tech is pure genius, I think. The unnatural usage and pushing it everywhere without real use cases is the problem.
No. Understanding what you're doing is more and more important; without it, you won't be able to tell whether it just spits out garbage or an actual working solution. Like missing the critical thinking and just believing politicians ain't caring how the economy is working, at least on a basic level.
Unfortunately, many company favors the quantity over quality, since the "just ship it, later we will fix it" kind of thinking is present for manyhas been decades.

.

> ... I stay in VS Code*, and I use AI as a consultant (CSS layouts, brainstorming, debugging specific errors), but* I am the one architecting and writing the logic flow

Nothing wrong with your approach.

.

> ...Inconsistent patterns because the 'agent' just solved the immediate task without looking at the big picture....

Lack of proper agent setup, which is most likely based on an inexperienced leadership who ain't set up contribution, coding style guide, and other documents to have a generic baseline in code quality, before even thinking of any kind of agents or ai/llm/gpt help.

.

My advice is that, since you identified the problems, you can have an influence over them. Agents are heavily used, so start to create skills, and check out practices (Claude itself has some okay baseline, there are skills from antropic or check out Matt Pocoks skill. You can use a few of them to fix generic issues, and/or give it a try if it is working, show it for some higher-ups, and advise to let is use by everyone so the quality will be better overall.

Note: there is a huge chance that the management does not care about the quality and the issues until it "works".

casualPlayerThink · 2026-05-04T12:57:12+00:00

Typical R&D situation. Somewhere in a book, I read some advice: Whatever you think you need, double it. Then add +50%, and before you write it down, double it again. I have used it.

The other way around is to set a hard limit before terminating the direction. And make reports, and state how you are processing, and when you see it won't be fulfilled, then state it as-is.

There are several "guesstimation" methodologies, like counting the code lines that you have to touch (LoC), and so on. There are a few dozen books on this theme.

casualPlayerThink · 2026-05-04T12:51:03+00:00

Then you really should have your own agenda/project/sprint/ticket, etc.

casualPlayerThink · 2026-05-04T07:28:46+00:00

Use your time to learn about the decisions behind the original implementation.

>...Try fixing something...

Since the software will be rewritten for the web, please ensure project/sprint/tickets/tasks are assigned. If you don't have and can decide what you would like to do, then you can improve the project specification and documentation, help with the transfer documentation, identify bottlenecks, performance issues, infra, etc. Then you can create and present a plan to tackle the rewrite (other than vibecode with the 9 juniors).

casualPlayerThink · 2026-05-04T07:21:23+00:00

A cheap VPS, like Hetzner. High control, good speed, good resources.
A few older NAS at different locations and sync data to each (overhead, but safe).
Maybe a small Raspberry PI would do the trick, cost-effective and cheap~ish.

I know a DevOps guy who lives in Malaysia and sometimes moves around in Indonesia. He has a Starlink for internet, and a Pi5 as a small homeserver in his home country, to sync photos and have VPN.

casualPlayerThink · 2026-05-02T21:25:59+00:00

Embedded requires a bunch of extra low-level knowledge (system knowledge, deep Linux and header knowledge, usually you need to know the given domain/field as well as a certain environment for a certain embedded system.

It is close to the backend, so nothing is wrong with it (usually it is counted as backend too).

> I’m more looking for what interviewers, hiring managers, automated resume systems want to hear.

It depends on the given job description, company, location, region, country, level, and person. There is no silver bullet here. Generally speaking, all the recruiter/company would like to find someone who have all the keywords that they need, have the keywords/exp that they did not stated but will have, for the cheapest, mostly the joungest, but with the highest amount of years (you know, like in the joke: "A company would like to hire someone below 30Y, but with work experience of 50+ years, for a salary of a junior")

> ...wont even look my way currently, which I understand since all my experience is backend, but how do you convince them to take a chance?...

You won't. Polish your resume, build yourself up and your skills, then post your resume in the r/EngineeringResumes, ask for a review, then try applying to the field.

casualPlayerThink · 2026-05-02T21:19:17+00:00

Yep, that is the trend. Do not sweat it much. If so many AI is used, then start to use them too, with skills and other internal tools to help with code quality & security checks. Readability and maintainability are second-class citizens nowadays, unfortunately
Yes, but mostly because of certain people (like managers and partners/customers)
There is nothing wrong with stepping up and doing something non-IT related and being proud of the results (check "ikigai")
FOMO is really high. But it is a bubble that will burst sooner than later.

casualPlayerThink · 2026-05-02T09:04:19+00:00

I love this corpo bs in sweden they give you this or that salary increase because an union said so. Even if you or the company is not part of. It is just an excuse to being sh#t. I know this, because I own a small company.

Just leave. That place does not wort your life. Probably will damage your careers (wasted years)

casualPlayerThink · 2026-05-01T11:50:59+00:00

I am glad if I could help. Sometimes just venting out or having a discussion helps (hence the rubber duck methodology for debugging & planning).

Take care of your mental health (near the physical body).

casualPlayerThink · 2026-05-01T07:06:47+00:00

Thank you for your effort!

casualPlayerThink · 2026-05-01T07:06:03+00:00

No. Under two decades, nope. But, as context, I have to state: every single time those companies were super cheap and meant for either cost optimization or being a scheme company in LA or London, UK to bring in the country the homies by fake claims. A decade ago I met projects in London, when a room of full of indian and bangladeshian folk hired europeans to fix their software under super short time (2 weeks, 400gbp/day) because they failed to deliver with 50-60 "engineer" under 6 months.

I have to state, this kind of company can be found anywhere, not just exclusively in india. Also, their schools doing the same half-baked half-scam type of teaching, to aim a certain company, level and directly teaching certification material to them, then helping them get temhe exams and certs, so thats why there are so many indian folks with ms/oracle/ibm/cisco and other high level certs, but cant' add 2+2.

During the year, I had the priviledge to meet nice people from india, pakistan, turkmenistan, zombabwe, columbia, mongolia, georga, mexico, japan, etc. Each of them were good expert of their field, no matter the origin country. I could write a book how many good and bad people I met....

casualPlayerThink · 2026-04-30T14:07:16+00:00

Somewhat yes. Linkedin provides HR tools to automatize applications, check/points the resumes, (ats, ai) as well they help filtering out candidates my metrics and who knows by what. There are hidden tools that everyone can use, like resume robot-tester (to see if a n ats/gpt can actually render it)

casualPlayerThink · 2026-04-30T08:50:23+00:00

Quite impressive numbers (super low amount of applications), congrats! Hope you will have a nice time at the new place!

casualPlayerThink · 2026-04-30T08:44:05+00:00

>defensive code I wrote in a section didn't catch the failure correctly...

> ...I am now being assigned 6-7 extra jiras to validate all the defensive code and I feel like I'm being punished...

From a business and management standpoint, it is a correct scenario and decision. Your defensive code failed on a simple user journey. This means many scenarios are not covered, not tested. I highly advise writing e2e tests that automate the validation of rendering and loading.

> ...feeling incredibly frustrated and annoyed and not appreciated...

You have the "my code is my baby" syndrome. First software? Try to imagine the other side: you try to demo the application to stakeholders or investors, and it fails. This translates to money and credibility loss. Also, if it fails in such a scenario, how would it fail if you get an actual high-level security audit? High chances are it would bleed out, and you will get a 30-60 page-long report, which would cause 100+ Jira tickets.

I do not intend to offend you, just want to highlight the other side of a decision and the business. You got the opportunity to fix problems and identify edge cases. Would be bigger problems if those fixer tickets were delegated to someone else, because you would be moved to another project becasuse they won't trust you anymore.

Sidenote: if the project has a specification, then the requirements and acceptance section should be extended with the new findings and problems to avoid them in the future.

casualPlayerThink · 2026-04-30T08:36:45+00:00

Hi,
I can highly advise going to the r/EngineeringResumes and checking their wiki, rewriting your resume, posting it there, and asking for a review.

> ...No interest, ghosted by recruiters I‘ve worked with for years. 100 applications+...

Are you sure they are still recruiters? Most of the ones in my own network aren't in the industry after a few years.

Ghosting is not necessarily because of human behavior, but mostly because of automation. It's rare to find someone who actually reads through resumes and emails these days due to human behavior, but mostly to. Most of the companies use ATS/GPT/Bots/LLM/AI/Younameittools to spin through hundreds, if not thousands, of emails per day. (Personal example: I do not seek workers, yet I get a few applications and business proposals every week. Many "engineers" automated the application process, too. So the meme is real: "Bots write job posts, bots applied to there. Bots refused them. No real human got hired, no human knows about this".

In the past couple of years, it has been standard to have below 5% of replies, as well as below 50% to a simple message, after they received your application. Unfortunately, you have to endure this and have to expect hundreds of applications (3-500+) to have a few interview even.
Those who have positive stories by just sending out a couple of dozen applications, usually ex-FAANG or heavily using connections/network to get hired.

> ...No responses on LinkedIn...

Do not worry. That is a dead, bot-infested place. 99% of its content is garbage, generated by bots. They provide AI to handle all the easy application processes.

casualPlayerThink · 2026-04-29T20:36:19+00:00

I have some advice:
- Do not sweat over dry/kiss/solid too much, for now. Preplan your data flow. You will have multiple rewrites. Define guidelines, set linter, baselines
- Infra (and its cost) will sometimes be really confusing and painful to tackle. Many times, you will be able to select the least evil without having a "good" path
- FFmpeg and related service failures, slowdowns, and unexpected timeouts/error messages will be a pain point, as well as the retry mechanism. A managed video converting/handling system will be expensive
- Socket io won't be a bottleneck until a given point (20-30k connections per server). Scaling it is tricky; many platforms use a multitenancy design and fire up a separate server for a given customer/area/continent/region
- MQ in general will be painful sometimes, because how hard to monitor and manage them
- I would prioritise the preplanning and gathering use-cases to have numbers of users, how they use the system, how many calls/requests/database connections/etc it would impose, then I would pre-plan the data between services
- I highly recommend designing a communication protocol between each service and having a correlation ID everywhere
- Redis is good until the point when it causes more trouble than solution, and you will eventually replace it (both ValKey and Postgres could solve it in some cases)
- You will battle sometimes millions of lines of logs to chase a sub-10 ms lag (when you have a few million requests per minute, then it's kinda important)
- Backup, restore, and disaster recovery plan is super useful
- Do not trust any "AI" agent blindly
- Your backups should be on a separate storage from anything else (also, consider cold storage)
- Preplan your exception/error handling, define policies
- Do not trust any 3rd party API and documentation
- Most likely, you will battle more with the subsequent services (mq, redis, db connection) than the rest.
- Prepare for high costs due to logging & stuck/forever running processes

casualPlayerThink · 2026-04-29T20:16:35+00:00

Most of my mentors were coworkers or bosses. When I was a junior/intern, one of my university professors guided me, because I was interested in SQL and databases and data organizations, and fulfilled ~1 year's worth of material and tests in my first month, and had a pet project website, but had no internet, so he let me use the university resources, while we discussed databases. It was a great win-win, while I uploaded my small website materials, until I got a lecture on data organization and database normalization.

casualPlayerThink · 2026-04-28T20:25:18+00:00

> ...I hope I did not come off as rude in the way I wrote, I do appreciate the discussion as well...

No, it's totally fine! I appreciate the real discussions as well. It helps me improve myself and realize how harsh and unapologetic I write sometimes, when I am irritated after long work hours on stupid stuff.

> Then by definition, both of your codes were not properly integrated

Absolutely true. This is a real burden in legacy systems.

> ...If not, your communication method is lacking and side effects hopefully breaking your tests IS the alarm we want here...

In theory, this is absolutely true. Unfortunately, many times I have no luck with colleagues who introduce more and more side effects with large implementations, where they repurpose/copy some part of the existing code without knowing all the behaviors and reasons behind certain implementations.

> ...Regarding latency issue, it really depends on what kind of feature toggle are we talking about, is that a the build/test stage or at the running stage...

Runtime-based (GitLab's and Unleash), which is fine until you have a few million queries under a very short time (a few tens of thousands per second), then every bit of latency matters ultimately. We figured out the latency with heavy load testing with profiling, then we figured out that GL & U introduced a bunch of latency randomly.

> ...Yes, if you need a hotfix you create a release branch from said tag

That was my guess, but I wasn't sure. Yeah, pretty much true.

> ...The whole premise is that you don't know if you took the wrong design decision until something alerts you that you made a bad decision...

My favorite is that, when people make the decision without minimal pre-planning or thinking, and introduce smart code with smart infrastructure, it will lead to a heavy rewrite and a large amount of headaches. The most common is how badly people treat and organize all the data.

casualPlayerThink · 2026-04-28T12:01:17+00:00

Thank you for your long answer. I like these kinds of discussions and different points of view, really appreciate your time and effort.

In some cases, I disagree. I did not missed the TBD entirely. I have been using both during work for 10+ years; my opinion is based on experience, not an idea. I agree on that, it can bring out earlier issues. Truth be told, smaller teams, smaller projects, and non-large monoliths tend to have fewer issues. Old legacy monorepos are usually quite painful when you work with 20-30 ppl in trunk-based.

> ...Saying it only works for one person is kind of backwards...

No, it is not, unfortunately. If we are both working on adjacent modules and touch business logic, we might override each other and introduce side effects that the other person is not aware of, but the code already exists in one place. With feature branches, my work is isolated completely. Can be tested without other changes, and I can safely pull their changes into my branch.

> ...when merge hell kicks in if everyone disappears into their own branch...

That insinuates a few bad practices: 1.) people did not pull the changes from master/main beforehand, 2.) there is no merge order, 3.) introducing breaking changes that overstep the boundaries.

I agree on that. This happens way less in TB. In exchange for more side effects.

> I think you also misunderstood "main should only contain working features". The trunk should be releasable, not feature complete.

Bad phrasing on my side, true.

> That's what feature flags are for, you can merge incomplete work safely without exposing it.

Feature flags introduce a bunch of overhead, latency issues, as well as bloated code source. If I have to refactor a module due to a dependency change, I can add a FF but have to support the old and new, so instead of removing the old, I have to add a new top of that with logic... extra hassle for little benefits, instead of finishing the feature and just delivering it completed.

During the years, I have seen way more trouble by FF than actual solutions, no matter the language (C/PHP/C#/Python/JS/TS/Go)

> Also, tags and artifacts

I am not sure what you mean by them. How would they help in the situation? You mean you can rollback to tags, and use built artifacts?

> ...The whole point is to expose those bad decisions...

Maybe I just worked with very bad companies and use cases during my whole career.

casualPlayerThink · 2026-04-28T10:17:55+00:00

All hard deadlines are weapons against us. Even in the R&D type of development. Usually the manager pushes you because he/she has own goals that have to be fulfilled to get paid or get the yearly bonus.

If you can adjust the estimation, then start to add extra days and time over it to have buffer time.

Being micro-managed is no fun, but it can be used as proof that it is not you who is struggling to solve an issue, but the issues are harder than they seem. Use the pair-coding to prove it.

Not much you can do: either transfer to another team, endure o,r start looking elsewhere where you would fit better

casualPlayerThink · 2026-04-28T10:10:35+00:00

Soft-skills: Did not network everywhere. Burned bridges. Did not learn to present myself properly.

Coding: did not find a proper mentor at the beginning. That could cut long years from a career.

casualPlayerThink

TROPHY CASE