I recently wrote a small service to get a temperature LED panel on my computer case working. It required a proprietary program to pipe the sensor temps to the display, which only worked on Windows. Being on Linux (arch btw :P), there wouldn't be a way to get this to work. I had a lot of fun learning about how to reverse engineer the inputs/outputs the other software was doing and replicate it in Python.
I’ve had to drastically reduce the scope of my work, but not the Quality. Working alone, means smaller goals.
LLMs are a game-changer, here. They are helping me to re-expand my scope. I’m not where I was, while getting paid, but I’m getting a lot done.
I've gone down endless lengthy detours that often lead to dead ends, but I've learned an immense amount from the OS to CSS. It's finally coming together in a simpler way than I had previously envisioned. Hopefully this year it'll be ready.
Like, "is vibecoding good or bad?"
Depends! Probably fine for a shed and terrible for a skyscraper. Or maybe there are some things within the skyscraper that might be vibecodable? I don't know.
Where I live, permits are required for all sheds, and for those above a certain size you have to submit blueprints.
Yeah, nah. When I take my learnings home with me, it fails every time.
Usually, the scale of work necessary to maintain an enterprise-grade system rapidly outgrows the time I can reasonably allocate to it. In other cases, I lose interest because it's boring corporate crap.
I don't known how all of you "homelab" people put up with it. I have enough Linux boxes at work that demand too much care and feeding.
The author has a good point but it really isn't a two-way street. The hobby stuff can feed into your career, but letting it go the other way is usually either counterproductive, or bad for your mental health.
Don't tinker in your shed because you think it'll advance your career. You'll be disappointed. Sorry for the spoiler.
Tinker in your shed because it makes you happy, and brings joy and meaning to your life. You'll be more productive and, in my experience, you'll actually be more likely to learn something useful for work.
> You try something in the shed on a weekend because you’re curious. You learn the tradeoffs, the rough edges, the things the documentation doesn’t tell you. Then months later, when the team at work is evaluating that same tool or approach, you’re not starting from zero.
These are two opposing concepts, but both True and complementary.
Working for clients (or companies) and home-based side projects are two sides of the same coin and complement each other. What must drive you, in both cases, is curiosity and the passion to do something useful.
My dream is to be able to turn a home-based project into something that generates income. My goal is to have the freedom to work on what I love and on a useful and profitable project of my own.
I had this idea where people's inventions/devices could be sent around in a "pay-it-forward circle" for learning and inspiration. People already do that with crystals.
Also, can being aware that x number of people are working on the same thing yield to development in the state-of-the-art if they start working together?
I suppose there's always that tension between DIY'ers bouncing ideas off each other vs prototypes built in fitted-out research labs to think about.
Is this idea anything more that just the addition of another sub-reddit or using existing teamwork software?
If you had something to share, how would you choose it amongst the 10's or 100's of things you have already built? Maybe you'd need commercialization help? Are there liabilities and risks in sharing DIY devices?
I've been thinking about https://openhardware.directory/ and https://ohwr.org/ - maybe if you list your projects, agents can do the work of bringing people together and finding new ways to develop them. It's about value-adding on top of decentralized and disjointed projects. An easy way to construct plans or follow them? How to minimize duplicated work across the world?
Maybe a "Universal Commerce Protocol" (http://ucp.dev) but for scientists?
Nowadays it's hard though, learning a new language, with a gf and a full-time demanding job, I don't have a lot of time to be tinkering. I do feel a bit sad about this but just assumed it's just life, and cannot imagine with kids how impossible this'd be.
I did look at doing some basic housekeeping with LLMs (updating deps, standardize testing across projects, etc) and realized I have literally 200+ side projects, most of them websites/JS libraries/React libraries. I was a bit baffled, of course 80% of it is trash, but I was kind of amazed at how many things I've actually done.
During lockdown I worked in there professionally, which was a mistake. It turned what was a creative space into something that had the emotional stick of a bad workplace.
However. I have mostly overcome that now. If you want to see how I built it: https://www.secretbatcave.co.uk/house/shed/
my most recent "finished" project is this: https://www.secretbatcave.co.uk/projects/despatchbox-pro/ which doesn't contain any electronics. This is unusual for me.
The projects I am most proud of are:
https://www.secretbatcave.co.uk/projects/electromechanical-c... Which is a clock using a tuning fork
and https://www.secretbatcave.co.uk/projects/stock-ticker-machin... which is a facsimile of a stock ticker
No more coding after 5pm!
For people who like doing other things, work already takes up most of their time and energy 5/7 days, and there doesn't seem to be much time for much else.
Did them, the games, the websites, the failed startup thing.
I just do other things now.
Building finance stuff during the day, doing little computer outside work (a bit of 3D printing here and there).
It’s fine. My career’s fine. The work doesn’t suffer from it.
Do I have the spark? Idk, I feel I am too old for that spark shit. There is work to do, I do it. If it’s tedious, I’ll drag me feet a while, but eventually it’ll be done. It’s just work.
ie. Yes, you could run a full on corporate CA, issue SSL certificates for your domains, manually rig up wireguard and run your own internal corporate VPN... or you just accept that your grand total of 1 concurrent user on an intranet is probably just better served by setting up Tailscale and a wildcard LE certificate so that the browser shuts up. (Which is still not great, but the argument over HTTPS and intranets is not for right now.)
Same with other deployment tools like Docker - yes, there's a ton of fancy ways to do persistent storage for serverless setups but get real: you're throwing the source folder in /opt/ and you have exactly one drive on that server. Save yourself the pain and just bind mount it to somewhere on your filesystem. Being able to back the folder up just with cp/rsync/rclone/scp is a lot easier than fiddling with docker's ambiguous mess of overlay2 subfolders.
Every overengineered decision of today is tomorrow's "goddammit I need to ssh into the server again for an unexpected edgecase".
You might think you are protected with UPSes and what not, but nothing will stop the electromagnetic effects if it hits within a few feet. Every piece of copper is going to get lit up. No solution is 100% guaranteed here, but EC2 and snapshots is a hell of a lot more likely to survive a single event like that.
The trick is twofold: if it isn't 'declare and deploy' don't run it. If it isn't in your backup/restore pipeline don't run it.
Pfsense and Home assistant are huge pains in the ass. Everything else is easy breezy.
Proxmox/pbs/truenas/talos/linstor/DRBD are all amazing.
I'm thinking about ditching pfsense for tailscale/cloudflare tunnels, but it's not worth the time atm. I don't have a viable alternative for HA.
I have an actual shed that I spend time in, doing maintenance work, building physical items (latest one is an auto-refilling bird watering station), and making beer. Given my day job is so desk-bound, and so tech oriented, I find using my hands in my off-time to be very fulfilling and what keeps me sane.
Different strokes, as they say.
Maybe because buildings are easy to describe the surface concepts to people without deep understanding of civil engineering or architecture or whatever, compared to other engineering disciplined like mech or chem or electrical.
Everyone knows what a building foundation is and why it's important, but if someone starts talking to you about negative roots being necessary for a stable linear time-invariant system, most people's eyes are going to glaze over.
But the skill and experience stick with you for lifetime.
No worries if this is a bit too forward. It just seems fun to brainstorm about a dream like this and we may have some complementary experiences.
But when I don’t have time and frankly energy, then I still try to do _some_ minutes of this kind of thing daily.
I feel like there‘s a big difference between 0min and 15min for anything (also includes exercise, meditation etc.), and while it’s great to have more time, there are diminishing returns beyond 30/45min.
You have all the time in the world, what you don't have is priorities.
That said, the second paragraph has the distinctive stocatto tone of AI
But AI is shaping how we write, so this could well all be hand written just by someone who spends time with AI output.
That said, I think your day job is more enjoyable when you see your work as a craft. It becomes less of a chore, you feel more engaged, and generally happier, which ultimately has a positive impact on your work and your colleagues. This has been my very fuzzy experience over the years, going through periods of both, but there are no definitive perspectives either way.
i got out of tech/coding so i could apply my skills to more real world stuff. it's been so much better. i don't make as much but i end each day with a feeling of satisfaction and accomplishment. i wouldn't trade it away. my social life has gotten so much better, as well, because i'm happier in general and i talk to so many more people as a result. i smile more, i think is the main thing.
Which is unfair of course. A) I don’t even know whether it was actually was written by AI and B) even if it was, it still encapsulates a human’s potentially worthwhile thoughts and experiences.
But.. undeniably genAI will lead to a much greater volume of text being written so we’ll all have to be even more selective in what we read and what not?
https://www.lathetrolls.com/viewtopic.php?f=17&t=10610
How funny would it be if one of the AI firms started offering free web hosting, just to get good UGC back? They could even block bots from competitors, right?
Be careful of calling this an ideal employee.
I, for example, tend to have a little bit of such a schedule, but what I work on at home is so much more exciting, making the job much more frustrating in comparison. Also, one is typically not allowed (or it is not possible) to apply all the really good ideas that one tested/implemented for the home projects at work.
Thus, the kind of employees who apply such a pattern are often very, very passionate about programming - but this kind of passion often makes them
- more frustrated at work (i.e. they might be cynical),
- less subservient (they often know better - from their "night work" - that a requirement makes no sense, and may be vocal about it),
- very opinionated about their "technological taste", not necessarily fitting the technological taste that the employer would love to see in the work (they have seen a lot more programming techniques).
Nearly all the local frame builders were using their parts, especially the rear dropouts.
I have a prioritised list, it's simply that not everything fits inside the list, because my time is limited.
Instead of "Not enough time" we could say "This is not high enough a priority".
[0]: https://marcusolang.substack.com/p/im-kenyan-i-dont-write-li...
Staccato, which is Italian for "detached, separated".
When I see simple Italian words used as technical terms in music or art, I think "oh, this must be what English speakers feel when they work in tech - a lot of common words becoming specific concepts in that particular field".
The next step is keeping the homelab at arm's length from stuff you actually depend on. My pfsense router Just Works with tons of cool stuff on it but if I get the itch to push it a bit further... walk away and make a VM in the shed!
I wonder if it'd be possible to create a Hackaday-type site with HN content. hackernewsbooks.com >> hackernewshacks.com
Before having built a more regular habit I was often in a sort of excitement-burnout loop. That doesn’t work well for me.
That said, I struggle with this as well, so I'm speaking more aspirationally than from a place of wisdom. :)
Constructing a skyscraper is a massive undertaking. You need architectural blueprints, council permits, and safety audits before the first piece of steel is even ordered. It requires hundreds of people coordinating over months or years. You can’t just throw up some drywall and hope the building holds weight.
Then there is the backyard shed. No blueprints, no permits, no audits. You just grab some timber, a saw, and start hammering. It might be a little drafty, and the roof might leak if it rains too hard, but you built it yourself in a single weekend.
For the last six years, my life as an engineer was split between these two modes. By day, I was building banking systems at enterprise scale. By night, I was in the shed, building whatever I felt like. Side projects that sometimes went somewhere and sometimes didn’t.
It is easy to view these as two separate lives: the work you do for a paycheck and the work you do for fun. But looking back on this chapter of my career, I’ve realised something fundamental. The enterprise work taught me how to engineer at scale, but it was the personal projects that kept me an engineer.
I’ve always told younger developers that maintaining side projects will do more for your career than any amount of interview prep and LeetCode will.
Early on, what stands out is how much of the work isn’t actually writing code. There are design documents, test plans, architecture reviews. It can feel like the actual building part is a fraction of the job.
But that surrounding work is what makes the building possible at scale. When you’re processing the volume of transactions a major bank handles, you can’t skip the design phase or cut corners on testing. Each of those steps exists because someone before you learned the hard way what happens without it.
Working in that environment gives you access to unattainable scale. You get to work with tools like Cloud Spanner, a globally distributed, strongly consistent database that you simply cannot simulate on a laptop. You learn defensive design. You start thinking about failure modes before you think about features.
But that scale comes with a cost: rigidity. You are a single worker on a massive site. You don’t often get to choose the materials, and you rarely get to experiment with the foundation.
The shed is where you take the blueprints you learned on the job and actually get to play with them.
In the early days, my personal projects were messy. Architecture was an afterthought if it was a thought at all. Classic shed behaviour. But over time, the patterns from work started bleeding in naturally.
You spend enough time designing systems that need to handle failure gracefully, and you start doing it on autopilot. The homelab is probably the best example of this. What started as a single container on a single machine turned into a managed cluster with automated deployments and infrastructure defined in code.
That’s taking the structural discipline from the skyscraper and applying it to a space where I had total freedom. The personal projects stopped falling over. They were still built fast and on my own terms, but they were anchored. The enterprise taught me the rules of structural integrity, but the shed gave me a place to actually be the architect.
When you’re building for yourself, the cost of a bad decision is a wasted evening. At work, choosing the wrong approach affects real teams and real customers.
That rapid feedback loop is what makes the shed so valuable. You are the developer, the reviewer, and the user. You can tear something down and rebuild it just to see how it feels.
I built a Game Boy Advance emulator in Go not because the world needed one, but because I wanted to understand how hardware works at that level. I’ve stood up services using tools I’d never touch at work just to understand their tradeoffs. You can try a tool you’ve never used before without writing a proposal for it.
Most of these experiments don’t turn into startup ideas, but they all leave something behind. A new pattern, a lesson in what not to do, a broader sense of what’s out there.
More than anything, the shed is where the curiosity stays alive. Enterprise work is highly valuable, but it can wear you down. Sprints blend together, the ticket queue never shrinks, and the problems start feeling repetitive. Personal projects are where you go to remember that building software is actually fun.
Earlier in my career, I was new to containerisation and cloud infrastructure, and the learning curve at work was steep. But because I was standing up containerised systems and running them on GCP at home on my own time, the concepts landed faster. I was getting reps in from both sides.
This pattern repeated throughout my career. You try something in the shed on a weekend because you’re curious. You learn the tradeoffs, the rough edges, the things the documentation doesn’t tell you. Then months later, when the team at work is evaluating that same tool or approach, you’re not starting from zero.
Because you’ve already broken things in your own environment, already evaluated tools on your own, and already felt the pain points, you can show up at work and make informed calls instead of guesses.
The trap of software engineering is thinking that your day job is the entirety of your craft.
The engineer who only builds skyscrapers eventually burns out. The problems become repetitive, the process becomes suffocating, and the creative spark starts to dim. You stop building things because you want to, and start building them because the business says so. You lose your edge.
Protect your personal projects at all costs. It is where your curiosity lives, where you experiment, and where you define yourself as a builder rather than just an employee. The enterprise will teach you how to write code that survives, but the shed is what ensures you actually still want to write it.