If you're bored, it's probably time to start job hunting.
Dumb, overly broad question, but I gotta ask at some point - does anyone have suggestions for figuring out what industries are out there, what they're like, where one may want to try next, how one might break into them? Career navigation isn't my strong suit, as you can probably guess.
At least, that's one idea.
My experience is a bit more mitigated here as a junior dev. No one wants to recruit a software dev who has only webdev experience somewhere else.
Unless I have some serious open source contributions to prove myself I guess, but my point is it's not as straightforward or easy as I felt it is implied.
The post is largely targeted at beginners. I think giving this perspective to fresh grads can help them take a decision to atleast clear up the dilemma when they have to choose to work at a startup/corporate during internships or right after college.
The reason I wrote it was because during my four years at college, we had this perception that webdev was boring and nobody used to opt to interview for companies which were into it. And the joke was, "All you do is change the colors every 6 months". I had the chance to intern at a SaaS startup and then worked there for more than 2 years and then figured students back at college needs to know more about this experience.
That said, the learning curve before HTML/CSS is "pain free" to develop with is huge. Especially compared to mobile frameworks, a native UI widget is easier to style and place on the screen. Also it'll probably keep rendering properly for the foreseeable future. (Or write a Windows app and it'll keep working until the end of time! :)
I've struggled a bit when I have to switch over to writing back end code for my startup. Some of it is mentally rewarding, writing a scheduling system for example, but other parts are just tedious, especially the CRUD stuff.
Of course worst of all was writing the scripts for and documenting how to do deployments. People who enjoy DevOps are kinda weird. ;)
As an aside, awhile back I threw together a simple WinForms app to do some trivial CRUD work in my DB. I have full Auth + Data Binding + UI working in ~2 hours. I hadn't used C# or Winforms in a few years. Porting that same UI over to the web took way too long. Getting the tooling up and running was a day! I hit a bug involving a release version of some NPM package that took hours to debug and then the framework I installed was using the globally installed version of Typescript instead of its own local version which took while to figure out and, well, a few more things like that. :/
Working in startups - especially if they have funding, is definitely not what I'd call boring.
If you're thinking about a startup, you need to be comfortable doing full stack dev, testing, infrastructure, operations, debugging in production, debugging on your local dev, databases both querying and architecture, unit testing, integration testing, functional testing, scalability and being able to be ripped out of whatever it is you're doing that needed to be finished yesterday to debug the server that just went down taking out your primary income stream; and then when it's done and you've high fived a couple of people, you need to be able to sit right back down and get the shit out of the door you got ripped away from to do that.
This is startup life. If you don't like the heat, you'd definitely better stay out of the kitchen.
If you're working in a startup and you're finding it boring, then chances are this startup isn't going anywhere. Time to get your CV out.
This list is good advice for anyone, not just startup employees. It's also really optimistic as pertains to startups, and comes off as some myth-making stuff. (Startups don't deserve myth-making and they definitely aren't glamorous. If it isn't your baby, then it's a job. Woe betide you if you don't keep that in mind.)
I agree that anybody should be capable of those things--though to be honest I say that about wherever you're working, "specialization is for insects" is one of the only Heinlein quotes teenage-me liked that I think still fits--but the reality is that the overwhelming, overwhelming majority of developers at startups don't have most of those skillsets when they walk in the door.
I consulted for quite a while and most of my clients were startups. In my experience, most startups before or at the "elbow curve" of growth have zero to "a few" senior engineers (the group of whom may include the technical co-founder/co-founders) with a broad skillset, a lot of juniors (the group of whom may include the technical co-founder/co-founders, they just don't know it yet) who have fallen for an okeydoke of an under-market salary and toilet-paper options, and zero to one principal engineer (the group of whom may include one of the technical co-founders) who is paid something within smoke-signal distance of market rate and is expected to perform miracles on a daily basis.
You will, to be clear, learn a lot of the stuff in that list if you're at a small, growing startup; you'll have to. Whether you do it right, or whether you do it right enough to do it at your next job...good question. I really wouldn't expect most developers to party on in with even a majority of those things already nailed down, though.
If they did, most startups couldn't afford them.
And yes, in a startup you will learn these things, whether you want to or not... and that growth curve will be painful. And you'll either thrive, or you'll die.
Painful, Yes.
I have programmed to the Web in 20 years and it has become worse over the years.
I believe, that if you make an effort and stay vanilla you will enjoy the work many fold.
I love the Web but it's not the Web it was yesterday. Unfortuneatly imho
It's frustrating as all hell though. Debuggers and tooling are in a pretty sad state in comparison to what I'm used to developing server-side and desktop applications, and the iteration loop for making simple changes can be pretty bad, depending on how involved your JS compilation and build pipeline is.
I kind of divide web development into three eras: pre-jQuery, jQuery, and post-jQuery. There was a lot of thrash in the pre-jQuery-to-jQuery era; remember MooTools? my first job was using that in 2010, that sure was a time to be doing that kind of thing. I missed most of the jQuery era because I was busy building the systems that the jQuery folks talked to, so I can't speak too much about that, but it seemed relatively stable, if not static, for a long time. And just as I was getting back into web development there was also a lot of thrash in the jQuery-to-post-jQuery era; Angular 1 or Angular 2 while wearing your regulation blue tie or React cool-kids wearing sunglasses at night and you've got the Ember guys over here quietly doing things and I am contractually obligated to mention Vue or I will have between two and thirty responses saying that I forgot about Vue, it's the Ansible of the frontend world.
But at this point it seems...mostly stable? The browsers are mostly predictable and mostly cover everything the 99% case cares about, everybody's browser engine is fast enough even if it isn't fast, and the various ecosystems out there have off-the-shelf solutions for most things and the crowd of Github starrers have given the rest of us decent signals as to what we should give a real look at. I feel like debuggers have gotten a lot better, though admittedly not at the level of something like IntelliJ; I have VSCode set up to breakpoint TypeScript (aside: a lot of what made frontend/JS development suck a lot less was TypeScript winning the metaphorical war) in Firefox and the experience is pretty clean.
Build pipelines can still be bad. Kind of a "doctor, it hurts when I do this" problem, though. Happy-path pipelines seem pretty speedy, although I do most of my development on a thoroughly un-heat-throttled Linux desktop rather than the metric standard Macbook Pro.
I did like the idea of taking a break before product launch. The push to make a deadline carried forward into a release brings charged emotions that won't match the new users'.
Is that because it's boring, or is it because people think front end is easy/straightforward and then realize it's not? I'd argue that the front end is a much more difficult task than the backend in the beginning of a startup.
There is more to web development than putting in style properties. For example I deem TypeScript one of the nicest language I've ever worked it, and React (Native; especially after they introduced hooks), and WASM fascinating technologies.
