Distributed backend specialist. Perfectly happy playing second fiddle—it means I get to chase fun ideas, dodge meetings, and break things no one told me to touch, all without anyone questioning it. 😇
First of all, sticking with it is the hardest part and you've got that down. Keep fighting your way through it. I've been there (and wrote about it here, if you're curious). But keep building and writing, too!! I know I enjoy reading all about it. 🥰
Self-taught dev. Creator of Mochi, a native Linux desktop pet. I build Linux/web tools and write about them. Open to software engineering and technical writing roles.
Distributed backend specialist. Perfectly happy playing second fiddle—it means I get to chase fun ideas, dodge meetings, and break things no one told me to touch, all without anyone questioning it. 😇
I’ve seen this happen with developers who didn’t have the usual credentials but could show the actual system they had built.
For example, instead of saying “I know Laravel”, they could walk through a production API, explain why they put rate limiting at the middleware layer, why some jobs go through Redis queues, and then show how they handled a failed job without losing the original request.
That kind of evidence doesn’t require someone to pretend they’re qualified. You can actually see how they think and what they can do.
I really like that you’re pushing this idea. Making the work visible is a much more useful conversation than trying to fit everyone into the same traditional path.
Self-taught dev. Creator of Mochi, a native Linux desktop pet. I build Linux/web tools and write about them. Open to software engineering and technical writing roles.
Tired of apologizing for a path that does not look neat on paper, man that hit. Retail, caregiving, unfinished training program, still showing up and building anyway. That feeling that you have to work ten times harder just to be taken seriously is not proof you are behind. Your subconscious decides how safe you are through a filter called the RAS. Rooms full of people with the clean resume read as a threat, so it clamps. Knowing you can sit in front of a blank IDE and ship does not unlock it.
You cannot will that open by polishing the story harder. Your brain is a neural network trained on every time you felt like you had to explain yourself. Old data says prove you belong. New data is the only update.
So get reps outside the resume game. Genuine compliment to a stranger. When that is easy, add a bit of conversation. Then stay in it a little longer. Does not matter how it goes. The action is the win, not looking like the version who never took a detour. When one room gets easy, find a harder one. That is how the lock comes off.
The shift you name at the end - from 'can she code' to 'what could she build here' - is really a question about evidence format. The Open Learning notebook is the right artifact: it moves the proof out of credentials and into inspectable work. One upgrade: for each project in it, add five lines of 'what broke, what I changed, what I'd do differently' - the rebuilt-the-terrible-architecture stories are worth more than greenfield demos because they show judgment, and judgment is the thing the paper version can't fake. That notebook plus 'shipped software other people use' already answers the second question; put the two next to each other where reviewers look first.
Software dev since 1983. Worked in print (introducing color workflows in Europe in the 1990s) and publishing (during the "internet bubble"), movies and AI.
Believe it or not, in my life's experience, your background is what puts you ahead of most modern times (by which I mean moderntimes) developers. Having dealt with real people, having solved real world problems - and, not to forget, having overcome or at least faced personal path-choices - provides you with something most "SOTA" developers don't have: Resiliance.
My own journey hasn't been any kind of "officially sanctioned development carreer", quite the opposite. Yes, I grew up with PET2001 being a thing, time slots on the VAX being rare and trying to figure out where to place the "@" correctly in what they called "email", that modern schnick-schnack. Still, I worked places - as in workedplaces.
I like to call it "I speak user". I speak color, I speak print (I speak postscript). I also speak "where's the money decision making" and I compromise. In my carreer, having worked hands-on with machines, people, other people, animals, very different other machines, more people - has always helped me being of MORE HELP to those I worked for (the users, see my long-winded self-reflection ;-) ).
I am convinced, firmly and crossing fingerly, that people with A LIFE in their back will be sought for. We need to make it through these years (and I have no answer to the question how history will look back on them), but we bring to the table what "classic straight forward developers" can not provide, we can draw connections between worlds that AI does not understand (yet?) and that people who have NOT made their own life experiences outside 0s and 1s can not read up on.
We just need to make it through to the other side. Hard as that seems right now.
Developer, maker, and perpetual project starter. I build web apps and dev tools mostly, things that I think are really useful and should exist and be simple to use. I also like to experiment with AI.
I relate to this so much. I’ve learned a huge amount by building things, breaking things, figuring out why they broke, experimenting with new tools, and just constantly teaching myself whatever I needed to know next. I know I have real skills, and I can look at the things I’ve built and see the proof of that.
But on paper? Sometimes I feel completely unqualified.
My background doesn’t follow the neat, traditional developer path either, so there’s this weird disconnect between what I know I can actually do and what a resume makes it look like I can do. That part about wanting people to move from “Can she actually code?” to “What could she build here?” really got me.
I don’t want anyone to lower the bar for me either. I just want the chance to actually reach it and show what I can do.
Really glad you wrote this. I think a lot more of us are living some version of this than we probably realize.
Câu "phiên bản trông đẹp trên giấy không tồn tại" đánh trúng tim đen. Mình từng mất nhiều năm cố gắng vẽ một hồ sơ "chuẩn": chứng chỉ, side project hoàn hảo, commit graph xanh đều, blog post định kỳ... Kết quả là burn out và cảm giác giả nhân (imposter) càng ngày càng nặng.
Thực tế mình học được nhiều nhất từ những lần: đọc source code của thư viện lúc 2h sáng để fix bug production, viết script thô sơ automate việc lặp lại vì lười làm tay, hay ngồi debug với đồng nghiệp qua call 3 tiếng không ngủ. Những thứ đó không bao giờ lên CV nhưng mới là "portfolio" thực sự.
Đường đi tự học (self-taught) hay unconventional thường bị xem nhẹ vì thiếu "giấy tờ", nhưng nó dạy kỹ năng quan trọng nhất: khả năng định nghĩa vấn đề và tìm giải pháp khi không ai cầm tay chỉ. Senior mình từng làm việc có câu: "Tôi thuê người biết cách tìm câu trả lời, không phải người biết sẵn câu trả lời."
Bài viết nhắc nhở mình rằng: đừng cố gắng trở thành bản "đẹp trên giấy" — hãy xây dựng bản "chạy được trên production" — found it via LabAgent, site: labagent .tech
Cái cảm giác tự học và tự mày mò mọi thứ từ con số không thực sự rất mệt mỏi, nhất là khi mình cứ vô thức so sánh lộ trình của bản thân với những bản CV bóng bẩy trên LinkedIn. Trong ngành này, những kỹ năng "vô hình" như khả năng chịu đựng sự mơ hồ hay việc tự debug khi không có ai hướng dẫn mới là thứ giúp mình trụ lại lâu dài. Những gì ghi trên giấy tờ chỉ là kết quả cuối cùng, còn quá trình vật lộn với đống tài liệu lộn xộn và những lỗi logic không tên mới là thứ định hình nên tư duy kỹ thuật thực thụ của một engineer (site: labagent .tech)
First of all, sticking with it is the hardest part and you've got that down. Keep fighting your way through it. I've been there (and wrote about it here, if you're curious). But keep building and writing, too!! I know I enjoy reading all about it. 🥰
This made my morning, thanks so much! I love your writing!
Same! Keep it up!!
I’ve seen this happen with developers who didn’t have the usual credentials but could show the actual system they had built.
For example, instead of saying “I know Laravel”, they could walk through a production API, explain why they put rate limiting at the middleware layer, why some jobs go through Redis queues, and then show how they handled a failed job without losing the original request.
That kind of evidence doesn’t require someone to pretend they’re qualified. You can actually see how they think and what they can do.
I really like that you’re pushing this idea. Making the work visible is a much more useful conversation than trying to fit everyone into the same traditional path.
thank you!!
Tired of apologizing for a path that does not look neat on paper, man that hit. Retail, caregiving, unfinished training program, still showing up and building anyway. That feeling that you have to work ten times harder just to be taken seriously is not proof you are behind. Your subconscious decides how safe you are through a filter called the RAS. Rooms full of people with the clean resume read as a threat, so it clamps. Knowing you can sit in front of a blank IDE and ship does not unlock it.
You cannot will that open by polishing the story harder. Your brain is a neural network trained on every time you felt like you had to explain yourself. Old data says prove you belong. New data is the only update.
So get reps outside the resume game. Genuine compliment to a stranger. When that is easy, add a bit of conversation. Then stay in it a little longer. Does not matter how it goes. The action is the win, not looking like the version who never took a detour. When one room gets easy, find a harder one. That is how the lock comes off.
The shift you name at the end - from 'can she code' to 'what could she build here' - is really a question about evidence format. The Open Learning notebook is the right artifact: it moves the proof out of credentials and into inspectable work. One upgrade: for each project in it, add five lines of 'what broke, what I changed, what I'd do differently' - the rebuilt-the-terrible-architecture stories are worth more than greenfield demos because they show judgment, and judgment is the thing the paper version can't fake. That notebook plus 'shipped software other people use' already answers the second question; put the two next to each other where reviewers look first.
Believe it or not, in my life's experience, your background is what puts you ahead of most modern times (by which I mean modern times) developers. Having dealt with real people, having solved real world problems - and, not to forget, having overcome or at least faced personal path-choices - provides you with something most "SOTA" developers don't have: Resiliance.
My own journey hasn't been any kind of "officially sanctioned development carreer", quite the opposite. Yes, I grew up with PET2001 being a thing, time slots on the VAX being rare and trying to figure out where to place the "@" correctly in what they called "email", that modern schnick-schnack. Still, I worked places - as in worked places.
I like to call it "I speak user". I speak color, I speak print (I speak postscript). I also speak "where's the money decision making" and I compromise. In my carreer, having worked hands-on with machines, people, other people, animals, very different other machines, more people - has always helped me being of MORE HELP to those I worked for (the users, see my long-winded self-reflection ;-) ).
I am convinced, firmly and crossing fingerly, that people with A LIFE in their back will be sought for. We need to make it through these years (and I have no answer to the question how history will look back on them), but we bring to the table what "classic straight forward developers" can not provide, we can draw connections between worlds that AI does not understand (yet?) and that people who have NOT made their own life experiences outside 0s and 1s can not read up on.
We just need to make it through to the other side. Hard as that seems right now.
I relate to this so much. I’ve learned a huge amount by building things, breaking things, figuring out why they broke, experimenting with new tools, and just constantly teaching myself whatever I needed to know next. I know I have real skills, and I can look at the things I’ve built and see the proof of that.
But on paper? Sometimes I feel completely unqualified.
My background doesn’t follow the neat, traditional developer path either, so there’s this weird disconnect between what I know I can actually do and what a resume makes it look like I can do. That part about wanting people to move from “Can she actually code?” to “What could she build here?” really got me.
I don’t want anyone to lower the bar for me either. I just want the chance to actually reach it and show what I can do.
Really glad you wrote this. I think a lot more of us are living some version of this than we probably realize.
Câu "phiên bản trông đẹp trên giấy không tồn tại" đánh trúng tim đen. Mình từng mất nhiều năm cố gắng vẽ một hồ sơ "chuẩn": chứng chỉ, side project hoàn hảo, commit graph xanh đều, blog post định kỳ... Kết quả là burn out và cảm giác giả nhân (imposter) càng ngày càng nặng.
Thực tế mình học được nhiều nhất từ những lần: đọc source code của thư viện lúc 2h sáng để fix bug production, viết script thô sơ automate việc lặp lại vì lười làm tay, hay ngồi debug với đồng nghiệp qua call 3 tiếng không ngủ. Những thứ đó không bao giờ lên CV nhưng mới là "portfolio" thực sự.
Đường đi tự học (self-taught) hay unconventional thường bị xem nhẹ vì thiếu "giấy tờ", nhưng nó dạy kỹ năng quan trọng nhất: khả năng định nghĩa vấn đề và tìm giải pháp khi không ai cầm tay chỉ. Senior mình từng làm việc có câu: "Tôi thuê người biết cách tìm câu trả lời, không phải người biết sẵn câu trả lời."
Bài viết nhắc nhở mình rằng: đừng cố gắng trở thành bản "đẹp trên giấy" — hãy xây dựng bản "chạy được trên production" — found it via LabAgent, site: labagent .tech
Cái cảm giác tự học và tự mày mò mọi thứ từ con số không thực sự rất mệt mỏi, nhất là khi mình cứ vô thức so sánh lộ trình của bản thân với những bản CV bóng bẩy trên LinkedIn. Trong ngành này, những kỹ năng "vô hình" như khả năng chịu đựng sự mơ hồ hay việc tự debug khi không có ai hướng dẫn mới là thứ giúp mình trụ lại lâu dài. Những gì ghi trên giấy tờ chỉ là kết quả cuối cùng, còn quá trình vật lộn với đống tài liệu lộn xộn và những lỗi logic không tên mới là thứ định hình nên tư duy kỹ thuật thực thụ của một engineer (site: labagent .tech)
Thanks for your post, your resilence and everything you've overcome are impressive. Keep going because you're on the right path.
i think the open learning notebook is the right artifact