Is it boring working in Web Development startups?(dev.to)
dev.to
Is it boring working in Web Development startups?
https://dev.to/ivarojha/is-it-boring-working-in-web-development-startups-1715
32 comments
Hiya! Author here. I can't comment on why you felt this was clickbaity. The intention was to give a third-person perspective of the life of an engineer as a webdev at a startup, emphasis on _startup_.
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.
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.
> If you do think it's boring, there are a lot of industries that need programmers to solve different problems in different ways.
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.
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.
As a general rule of thumb (not that I'm great at this), physical networking might be the most tried and true. Look at whatever local conferences there are, go there, ask people what they do and what challenges they face. Their challenges could be your opportunities if you can find a way to leverage your strengths to solve them in a way that they can afford/use.
At least, that's one idea.
At least, that's one idea.
That's actually a really good question. The thing is, this differs wildly on where you are (or where you want to be, geographically wise). In some cities, you might see entirely different positions just because there are different companies with different needs (e.g. security analysts near big bank headquarters). I too would like a general list of popular programming-related positions though.
> If you do think it's boring, there are a lot of industries that need programmers to solve different problems in different ways.
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.
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.
Web dev is a fairly broad term. If you only know Angular/CSS/Typescript, you're kinda out of luck unless you start brushing up on your Node chops. If you're writing web APIs, it's a much smaller jump. Embedded systems are a whole different ballgame though.
I'm full stack, react/redux/typescript front end, and restful api in go/python for the back end. So I presume the jump is not that high in theory, but there are always better fitting candidates.
I'm not saying you are wrong though. Just trying to tell the other new grads that switching might not be straightforward and might require some effort on their part.
I'm not saying you are wrong though. Just trying to tell the other new grads that switching might not be straightforward and might require some effort on their part.
In my experience, working in startups is anything but boring. You have to wear all hats and solve all problems. You have to be ready to think on your feet. You've gotta be able to think fast and act and be able to deal with the consequences of your actions on the fly. This is start up life. It's exciting, but it's stressful. Some might call it a baptism of fire.
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.
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.
Right on! This freedom to wear many hats is what makes working at startups such a lively place. Startup is chaos and finding ways to contribute to the overall business eliminating the chaos is what makes your worth.
> If you're thinking about a startup, you need to be comfortable doing ...
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.
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.
Yep, eventually you become sufficiently skilled at enough of those disciplines as to be able to call yourself a specialist in many/most of them. At which point, you're either in high enough demand that only those that are desperate for you are willing to pay, or you're priced out of the market... or you still just do it for fun.
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.
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.
Doing it for the love of the game is certainly an option, I don't mean to exclude that. I'm going to my next gig for something a little under-market because I think they're good people and I like the vibe there. (It helps that there's a big video component to what they do, and I do a lot of video stuff for fun already and want to learn and contribute there in addition to my usual infra/mobile/frontend/backend nonsense.)
Just saying that most people coming in the door, the sorts of folks who are going to be asking this sort of question, are just not in the same position as you or I are. ;)
Just saying that most people coming in the door, the sorts of folks who are going to be asking this sort of question, are just not in the same position as you or I are. ;)
I went from corporate to startup... and now I just don't seem to be able to go back to corporate. Once you've had that baptism, if it didn't kill you, it's part of you. There's no going back to sitting in a cubicle after that kind of excitement.
The heroification and myth-making is, again, I think a little much. It's a job, it's working to make somebody else wealthy. It's not "a part of you" any more than any other job; it just becomes what you're used to.
Frankly I think most people who have taken a few turns in startup-land should try freelance consulting on for size. I'm explicitly not doing it right now for other, personal reasons, but I'll go back to it eventually; it's the arena in which your skills are really as-fairly-as-possible valued and where you can realize some really outlandishly-sized gains for a lot of organizations if you hustle.
And, having spent time in startups, you've already internalized that your job might disappear tomorrow. ;) Consulting at least lets you spread out that risk both in terms of clients and in terms of billing.
Frankly I think most people who have taken a few turns in startup-land should try freelance consulting on for size. I'm explicitly not doing it right now for other, personal reasons, but I'll go back to it eventually; it's the arena in which your skills are really as-fairly-as-possible valued and where you can realize some really outlandishly-sized gains for a lot of organizations if you hustle.
And, having spent time in startups, you've already internalized that your job might disappear tomorrow. ;) Consulting at least lets you spread out that risk both in terms of clients and in terms of billing.
It's not about heroification and myth-making or what you're used to. It's entirely about the excitement found in the chaos, and either you thrive on that, or you hate it... or you get Stockholm Syndrome and learn to love it because of the psychological trauma of running that gauntlet.
It's stressful for sure, in a manner not dissimilar to jumping out of a plane for the first time. The rollercoaster of emotions. The dread and worry about how the fuck you're going to pull off the impossible. The heartbreak you feel as you think you're just not going to be good enough to pull it off this time. The relief when you manage it again. The exhilaration of having come through it, perhaps with some bumps and bruises, but you made it and it didn't kill you.
Work in this kind of environment long enough and it will either break you or make you feel like there's nothing you can't do. One thing's for certain though, it does change you, in a way that those who haven't worked in startups will never quite understand.
Consulting is certainly a different mindset. You can either become attached to the project and make it as much your baby as the rest of the team, or you can function as mentor and help them to grow to the point they can handle it themselves. There's a lot of satisfaction in this. I find that the more emotionally involved I am in a project, the more fulfilling it is. The more detached I remain, the less so. I get a lot of enjoyment about being part of a team coming together for the achievement of a goal - even if that goal is to make someone else rich. When a project is personal, and by personal, I mean I'm emotionally attached to the outcome and I am vested in seeing it succeed, the emotional highs and lows are where the magic is found... that's what makes me feel alive and that is what I live for.
It's stressful for sure, in a manner not dissimilar to jumping out of a plane for the first time. The rollercoaster of emotions. The dread and worry about how the fuck you're going to pull off the impossible. The heartbreak you feel as you think you're just not going to be good enough to pull it off this time. The relief when you manage it again. The exhilaration of having come through it, perhaps with some bumps and bruises, but you made it and it didn't kill you.
Work in this kind of environment long enough and it will either break you or make you feel like there's nothing you can't do. One thing's for certain though, it does change you, in a way that those who haven't worked in startups will never quite understand.
Consulting is certainly a different mindset. You can either become attached to the project and make it as much your baby as the rest of the team, or you can function as mentor and help them to grow to the point they can handle it themselves. There's a lot of satisfaction in this. I find that the more emotionally involved I am in a project, the more fulfilling it is. The more detached I remain, the less so. I get a lot of enjoyment about being part of a team coming together for the achievement of a goal - even if that goal is to make someone else rich. When a project is personal, and by personal, I mean I'm emotionally attached to the outcome and I am vested in seeing it succeed, the emotional highs and lows are where the magic is found... that's what makes me feel alive and that is what I live for.
I went from startup to corporate and back to startup. You can't resist the desire for instant gratification and feeling of accomplishments that you get at a startup. You become this "T-shaped person", and your knowledge bar on the _T_ keeps expanding because you get the chance to wear many hats, while still being able to expand the vertical bar of your expertise/develop new specialties.
This article seems to be saying that getting the data infrastructure built (i.e. backend) is the exciting part, but when it's time to build the front end it becomes boring.
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.
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.
If the title ends in a ?, the answer is a definitive "No".
"Should women have a right to vote?"
Closest I could find to a recursive Betteridge's Law: ;) http://calmerthanyouare.org/2015/03/19/betteridges-law.html
For many developers, UIs are often the most rewarding part of code to work on, the impact of making a change is immediate and obvious, and hey, pretty stuff is fun to make!
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. :/
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. :/
Huh, the rare and elusive Betteridge's law exception.
Not in mine ;-)
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.
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.
Boring, No.
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
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
Exactly, I wouldn't call it boring. Things break in interesting new ways all the time, and you have to constantly be learning, because the pace of change is so breakneck.
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.
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 feel like the pace of change has slowed a lot over the last few years, to be honest, and I wouldn't use that argument as a reason to not get into web development today.
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 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.
If work is boring, it's probably repetitive. If it's repetitive, you should automate it. I think this applies to any kind of development.
The article sets up the idea that 80-90% of a project gets done well, but the rest gets ignored because it is boring. However, the article does not describe what the boring parts are, or how to integrate them in scheduling to dull the pain.
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'.
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'.
Betteridge's Law applies https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
I find it boring, but that's why I'm trying to get out of the industry and find an alternate career. Software development has broke me.
If you're bored, it's probably time to start job hunting.