> a bunch of ancillary skills that you don't think of as programming, but you need to know them. Version control, devops-type stuff like how to provision a server.
As someone who first coded seriously 40 years ago, and who keeps in practice on side-projects, this is where I find it hardest to keep up: the complex tooling and processes around actually deploying your code in a production environment. Reading HN has been invaluable in maintaining some sort of awareness of what is current.
In interviews I began to notice that as I went from junior to senior, I got more questions about scalability than I did about actual logic in Java or javascript. So I started focusing on infrastructure more.
For one interview, the take home challenge was to write a bit.ly clone. I decided I would show off my abilities to do load balancing on the web server and horizontally scale a database.
I wrote my application with a dockerfile for ease of deployment. I set up multiple A records to point to each docker container's IP for a simple DNS round robin load balancing. Each container had a unique hash string printed in the bottom right corner of the website so you could demonstrate to yourself that load balancing was occurring.
I set up 3 postgres databases with simple modulo hashing for each shard; I use an 8 character hashing function (forget which) and did a modulo on the number of shards. This directed each shortened link to its relevant shard, with the shortened form of the link as the key (note: this is not the best solution to the problem; look up consistent hashing if you want a better solution). Which database connection string to use depended on the result of this modulo
All this was deployed with relevant kubernetes service and deployment yaml files, with ci/cd hooks provided by my VPS (I think vultr or digitalocean)
When I was explaining all this in the interview, I was actually interviewing with someone who was lower ranked than the job I was interviewing for (she was a junior engineer with maybe 2 or 3 years of experience, I was interviewing for a mid level role with 5 years of experience)
She said "so, it seems like you're more interested in devops than application development?"
I said "no, I actually really hate devops, but these are the skills I get interviewed on most so its what I practice".
That's probably for the best. If a company's using their junior devs to run the interviews, it probably also has a number of other pitfalls, hidden during the interview process...
It seemed like a nice company, but they always seemed out of time. It was difficult getting the recruiter to call me back, and they always scheduled things WAY out. They weren't even a big tech company, they were a mid size logistics company. Took me like 2 months of a handful of interviews to eventually tell them I'm not interested
I've stopped caring about what is current. I have carved out my own little world. It's beautiful, wonderful to work in, I'm extremely productive, and it makes enough I'll never need to work for others. I am happy to become a dinosaur and leave it to the young to rediscover things and enjoy the pain the old folks have known to avoid for so long.
Sure! For the past 10 years I've been making a 2D skeletal animation tool. It's a desktop app built with Java, so I get all the nice Java tooling, hotswap, etc. There's no Swing junk and it's not built like most productivity apps. It's built like a game using OpenGL and runs at 60+ FPS. It uses a lot of my own OSS, like libgdx and my 2D UI framework scene2d.ui. NIH is a thing but there is also a lot to be said about not needing to rely on others and wade through their messes. With this setup my productivity is super high.
Instead of scaling up the company and moving from a dev role to one of those nasty spreadsheet people, I stayed doing what I like. Even after 10 years I'm still the only developer on the desktop app, so all the code is mine from the start. No cruft! It's either pristine or my own uglies. I ran the company lean as long as possible. That was something like 5-6 years working long days, but I like working on it. Nowadays it's more relaxed and a handful of others work on runtimes and customer support.
The trick for me was to fill a niche that I was familiar with and leverage the tools and libraries I had already been working on for a long time. There were competitors already established in the niche. The now defunct Spriter had a 9 month head start. Flash actually comes close to competing, but you need to extract the animation data from it and write your own runtimes.
That is probably another reason Spine is successful. There are many tools for doing animation: Blender, After Effects, Moho, Toon Boom, etc. Those can be impressive if you're exporting video (eg making cartoons) but they aren't easy to bring into a game. Spine is similar in that you can make animation, but it also provides runtimes to render the animations in games/apps. Only a few competitors do that, and they do it pretty poorly as an add-on, while it's a main feature for Spine.
Spine is also set apart with a focus on good (if nonstandard) UI/UX, workflow, and polish. There are no right click context menus anywhere. That was a sort of experiment, but I like it. It forces placing functionality in UI that is discoverable. One reason UI is so important is that Spine succeeds by making the workers happy. Make a tool people love to use and they'll naturally push the businesses they work for to buy it, if only so they don't have to suffer some other tools. Couple that with Robin Hood style pricing so you are affordable for individuals but more expensive for businesses who can both afford a higher price and stand to gain more from using the tool.
I greatly dislike subscriptions. I won't buy any software that is subscription only, absolutely not ever. Given that, I also won't sell my software that way. Instead I sell to individuals a perpetual, lifetime license that gives ALL future updates. Some think that is crazy, leaving money on the table. It costs to bugfix and develop new features right? IMO it doesn't matter. It's more important to have many individuals using the latest version who will be proponents at their jobs. That leads to the next part, which is businesses pay annually. It's the same software, but the cost is per year per seat for a business. That gives recurring revenue and makes up for not gouging individuals with a bullshit subscription.
TL;DR is something boring like: find a niche, find ways to do things better, add value in new ways, and structure pricing to encourage individuals while taxing businesses.
Thank you for this reply. I actually created a micro saas basically on these principles, EXCEPT I made it for my father's industry.. which makes selling it and supporting it drudgery for me.
So I know it's possible and it was nice reading your writeup reminding me I wasn't just lucky. (My father's industry is very niche and basically had zero competitors for the segment of the market (20-50 employees).
My plan is to try again soon with something I am way more passionate about.
Even though I love working on my software, there are still a lot of business things that need to be taken care of. Even some aspects of building the software are not fun (eg, fuck Apple). Ultimately it's a job and even in the best case you have to push through a lot of bullshit to enjoy the good parts of doing the job and of course the rewards (revenue, having many people use and enjoy your work, etc).
The end game is to either sell out or hire others to handle the drudgery. Ideally you can work or not work as you choose and everything runs smoothly regardless. How much revenue you divert to that cause is up to how much you can stomach doing yourself. It took me 5-6 years to reach burn out and need assistance. Now I'm in that ideal zone and it's much more comfortable. I doubt I'll ever sell as I'd have too much free time.
I do think it's possible to have a product you hate and lots of reasons selling and supporting it can be horrible. I just wanted to point out that even if you loved it, you'd still have some of those aspects. Finding a successful toehold is difficult. You might try and fail a number of times before doing it again. I'd be wary about giving up on a success unless you're super sure the annoying bits can't be massaged enough to be tolerable.
One thing I haven't had to deal with is marketing. I started the business with a Kickstarter but otherwise never had to actively peddle my wares. That's mainly due to it being a niche market, that the nature of animation is flashy/appealing and doesn't need to be explained, and by focusing on UI/UX/polish so users enjoy using it.
Given how what's current seems to change every couple of years - and companies will rewrite their infrastructure to follow that to boot - I'm not really bothered with keeping up, it feels futile if my hard work will be undone by some upstart later on anyway. Just tell me how to deploy my code, that'll do. I'm more of a front-end developer anyway (by chance moreso than by choice, but then, back-end feels more tedious)
There's a disproportionate focus on it all too I think.
Cloud deployment and CI/CD and networking and all that stuff absolutely matter, and must be done right to avoid a world of pain, but often it's largely a one-time setup - and then you focus on the same old tried-and-tested coding techniques and principals to Get The App Done.
For example you spend a month on the infra, then a year building, maintaining and enhancing "the app".
Maybe I'm wrong but so much tech discussion here and elsewhere seems to be on the infra part, lately. But coding well, including interacting efficiently with resources such as DBs, just isn't as prominent I don't think?
Maybe there's nothing to say of course. Or maybe the old microservices-vs-monoliths is exactly that...
> Cloud deployment and CI/CD and networking and all that stuff absolutely matter, and must be done right to avoid a world of pain, but often it's largely a one-time setup
In my experience, this is not true. At any large company with thousands of engineers hammering the CI/CD/development thingys, a CI/CD failure is an incident unto itself. And it often requires A LOT of maintenance.
And you can't just offload it to gitlab or whatver because you WILL need to build abstractions over it.
What I have found particularly infuriating is large companies with billions of dollars in revenue choose to completely ignore the productivity decline that comes from poor CI/CD, and then demand faster work from engineers who are hamstrung by poor infrastructure.
Don't get me wrong - CI/CD itself is of course a product subject to ongoing evolution and challenges such as scaling, aging, vulnerabilities, etc.
But usually, I would expect that "Project ABC" will build all its infra and CI/CD usage early on and then just proceed to consume that CI/CD as a commodity service, with ad-hoc changes needed to continue playing nicely with that service.
>> What I have found particularly infuriating is large companies with billions of dollars in revenue choose to completely ignore the productivity decline that comes from poor CI/CD
> often it's largely a one-time setup - and then you focus on ... Get The App Done
That's what success looks like. Not everybody is successful, and from how people talk about it, it looks like a lot of people have never experienced it at all.
I've been programming for almost 40 years. Even majored in CS for a while, thinking I'd be a professional programmer. Every time I read about some new Javascript library or the latest microservices etc, I'm glad I went a different route. I probably write a lot more code today than I would as a software developer and I don't have to keep up with that stuff.
> the complex tooling and processes around actually deploying your code in a production environment
I agree. But in a professional settings, this is usually less of an issue. Everything is set up when you join. You still need to learn about the tools but you don't need to set up things for scratch like you would do for a personal project.
I remember how I was struggling to learn about Docker, renting instances on AWS, setting up services my app would need. This killed all the joy of my project. In my company, I routinely deploy hundreds of servers in data centers across the world, use all the managed DBs and various services available. Much simpler.
Sticking to cloud services that abstract a lot of this away can really help. If you aren’t deploying for “scale” then using managed services is the key. Not sure what the equivalent of heroku is nowadays, but they can remove a whole bunch of headaches.
I’ve also been pretty impressed with the serverless framework - particularly when used as a wrapper round traditional frameworks like flask or express.
As someone who first coded seriously 40 years ago, and who keeps in practice on side-projects, this is where I find it hardest to keep up: the complex tooling and processes around actually deploying your code in a production environment. Reading HN has been invaluable in maintaining some sort of awareness of what is current.