There is little difference between "experience programming during a job" and "experience programming for fun". It is the same activity.
Over of my more recent hobby projects was writing an RSS->IMAP bridge in maybe a couple hundred lines of Python. It has one user (me). This is fairly typical.
Until this year, my primary work project was a toolset for streamlining one-off ETL projects. It has parts written in I think five different languages, it has parts that run on Windows user machines and other parts that run on unix servers, it was built to reduce the annoying parts of a business process, it evolved over the course of almost a decade, etc. It has a couple dozen users (the team I used to be on).
The two are about as different as adding a new attached garage and workshop vs building a dollhouse.
Yeah, exactly. With the work frequently being the dollhouse.
At my various $dayjobs, I spent most of the time building various flavours of the same CRUD (web CRUD, desktop CRUD) in dumb mainstream languages. At home, I do everything from video games to data processing to AI, in actually productive languages.
The difference I see is that with hobby projects, you're at least free to make something that's actually useful. At work, you might get that if you're lucky. If you're not, you'll be implementing in code some dumb inter-management politicking.
This reminds of a situation I faced early in my career. We worked on a network alarm management tool, and some of us used to rewrite the tool or bulk of its features. To a point we finally arrived to invent our own tools to fill up the gaps in the feature set offered by the current tool.
It used to be one of the biggest reasons why we learned so many thing in comparison to the rest of the team(which was fairly big), to a point we could make a lot of very critical design decisions or write an application that could save hours of time for our users.
Its one of those axioms of software development I've learned, in order to do good work you have to do mountains worth of waste work.
> Its one of those axioms of software development I've learned, in order to do good work you have to do mountains worth of waste work.
It suggests an obvious question though: can we do better? Can we avoid having to do "mountains worth of waste work" before getting to do the "good work", or is the former a necessary prerequisite for the latter?
It's not just about skills, but also about knowing what problems to solve and being in the position to solve them. I wonder if we can side-step having to do waste work in the latter cases.
Over of my more recent hobby projects was writing an RSS->IMAP bridge in maybe a couple hundred lines of Python. It has one user (me). This is fairly typical.
Until this year, my primary work project was a toolset for streamlining one-off ETL projects. It has parts written in I think five different languages, it has parts that run on Windows user machines and other parts that run on unix servers, it was built to reduce the annoying parts of a business process, it evolved over the course of almost a decade, etc. It has a couple dozen users (the team I used to be on).
The two are about as different as adding a new attached garage and workshop vs building a dollhouse.