I don't think I have. I was an early employee at a startup that made it through a few rounds of funding. Somewhere in there the ship started sinking and it was pretty obvious.
In the beginning, we routinely worked 60+ hours a week and it didn't really bother me. But when it felt like no matter what I did my efforts wouldn't matter, I lost all my motivation and burned out. But I still couldn't bring myself to quit. I was emotionally invested in the company, our team, and our customers.
The second round of layoffs in a year (a 67% staff reduction) was the final nail for me. After I left I didn't work for at least six months. The first two months, I basically did nothing and got a lot of sleep. Then after that I decided to start doing all the things I never had time for. I cooked all my meals, I exercised, I traveled, I spent more time with family and friends, and I developed some hobbies outside of tech.
That was about five years ago. I've had 3 jobs since then, and I left each of them before a year was up. If the right amount of balance is just to have a job you punch in/out of that pays pretty well, I'm just not that interested. But I also know that there's no way I have another startup in me. For awhile now I've actually made more money with my "side hustle" than I can as an engineer, even though my cash flow is very uneven. So I think I'm basically done with software.
What's cool about this is now that you have a date generator, you can apply all kinds of fun things to your date ranges with Python's standard library.
Apply generator expressions, format them with map, filter out weekends, anything in itertools (dropwhile, takewhile), etc.
I wrote a datepicker to demonstrate some concepts like lazy evaluation with JavaScript generators and it was fun coming up with the test cases.
I worked at a startup that operated for over five years with a similar amount of funding. We had a web app, webpage, native mobile apps on both platforms, marketing, customer service, sales, and our own office that was pretty dope. We had something like 75 employees at the peak. I can't believe it either.
I've never gotten burned out from working too hard. I get burned out by having no say or control over what we are working on or how it's done, and by getting stuck working on low-value tasks for prolonged periods of time. Those projects are the ones that make me not excited at all to come to work.
It's usually because the client / product owner has no idea what they're doing but still insists on making all of the decisions with no input from users / developers / designers. And it sure sounds ridiculous, but it is the norm. Developers are viewed as people who do not want to participate in meetings or planning, and who exist on streams of work to do. If the developers run out of work, they'll go crazy! As long as we "keep them unblocked" and have tasks ready for them, we're doing our jobs and they'll be happy!
> I've never gotten burned out from working too hard.
Me neither. I burn out when I'm working on something that I don't love working on (and things like feeling powerless or bad management can make it something I don't love working on). Not coincidentally, I also don't work as hard on those things despite all good intentions.
This is why the #1 requirement I have when I'm considering a job is that it is something that I will enjoy. That's more important than compensation or location.
Another benefit is establishing team norms and best practices, which is also a goal of code review, but pairing accomplishes it in a bottom up way rather than a heavy top down way. I've worked on teams where review was a very important part of our process and it was common for code to be under review for days or even longer.
I have major gripes with it too and don't use it unless a project enforces it.
The main ones that get me are the whitespace (4 characters) and restrictive line length (79 characters) rules. They don't work well together, and also don't work well with python's significant whitespace (can't easily break up a line), namespaces, generator expressions, and type hints. All for a subjective formatting decision.
I'll also often see people trying to cram as much as they can into 79 characters with one letter variable names and such while calling that elegant code because it's a "one-liner."
Yes, the 79 character limit gets in my nerves. Unless you're using a machine built in the 70s or 80s, this limit is complete BS
To be honest it says right at the beginning of PEP-8 that "A Foolish Consistency is the Hobgoblin of Little Minds" but it seems little minds are the norm (and usage of 'pep8' package to make developers do what a computer could do faster and better)
Not the last, but near it. Also not the first, but near it. There's a huge difference between the two.
In my experience a sinking ship doesn't start floating, so don't stick around for that reason. It was also depressing to be there after all my friends had been laid off or quit. In reality I probably stayed there two years too long, and it was because of the people I worked with.
I've often wanted to write a compiler that would accept a schema definition like protobufs or graphql as input and generate the required SQL to update the database if a schema change was committed. It would also be read by the application layer so its model definitions were kept up to date.
As you say, there's a tremendous advantage in using triggers to remove data invariants, but then there's also the issue of the schema's state, and it can be prone to error depending on the complexity of the trigger. It's definitely recommended to use SQL's schema inspection to verify and test it. Perhaps even based on schema definitions from protobufs or whatever.
I understand the appeal and you're not the only person to want it: I've seen people and companies implement db schema to graphql, db schema to models, and models to db schema.
Based on personal experience, this is a bad idea though. You do not want a 1:1 correspondence between your database schema, your backend models, and your graphql schema, because the way you organise information in each layer should be different.
Database schema needs to be performant for expected queries. That means de/normalisation decisions; sometimes the same data will be stored in multiple locations.
Backend models need to express the domain, because this is where your business logic is. (There's a reason people bitch about ORMs: when you get to complex enough usecases they're not flexible enough in either direction and you need extra models wrapping THAT.)
Graphql schema is a view of your backend; sometimes several fields will be fulfilled using the same model, sometimes your model should not have a reflection in graphql schema (because you do not want to expose this data to frontend/the world), and sometimes your graphql schema will be full of deprecated fields because client apps have not been updated (see Facebook policy of never removing anything.)
Everything you say is so true. In a similar vein, all those ready-made REST libraries that help you shoehorn your business models into 1-to-1 mappings between them and your REST resources/endpoints, have no reason to exist. And yet you still see people battling with them.
REST is still HTTP + more exotic verbs + headers + more serializing/encoding options. You can build a small library, specific for you project's needs in a matter of 3-5 days. And on top of that, you don't forfeit any possible future optimizations, which you most certainly will by choosing any ready made library.
It's feasible to make such a tool to update the database schema so that it would match a changed definition, but I don't think that it's feasible for it to update the actual database.
To do that, you need knowledge about how and why the schema was altered, and schema definitions like protobufs or graphql don't contain that. For example, how would you distinguish between renamed column (where you need to keep the data) and deletion of a column plus adding a different one?
There's a reason why migrations are the standard level of abstraction, packaging changes to schema with scripts ensuring consistency of data throughout the whole version history.
In the beginning, we routinely worked 60+ hours a week and it didn't really bother me. But when it felt like no matter what I did my efforts wouldn't matter, I lost all my motivation and burned out. But I still couldn't bring myself to quit. I was emotionally invested in the company, our team, and our customers.
The second round of layoffs in a year (a 67% staff reduction) was the final nail for me. After I left I didn't work for at least six months. The first two months, I basically did nothing and got a lot of sleep. Then after that I decided to start doing all the things I never had time for. I cooked all my meals, I exercised, I traveled, I spent more time with family and friends, and I developed some hobbies outside of tech.
That was about five years ago. I've had 3 jobs since then, and I left each of them before a year was up. If the right amount of balance is just to have a job you punch in/out of that pays pretty well, I'm just not that interested. But I also know that there's no way I have another startup in me. For awhile now I've actually made more money with my "side hustle" than I can as an engineer, even though my cash flow is very uneven. So I think I'm basically done with software.