371–380 of 440 posts
> So, I will repeat it again: our greatest asset isn't the code we write. It’s us, alive, and living the life.
Happy people work harder, get more done, are more creative and ill less often.
It pays off for employees as well as employers to put life happiness first.
In almost 30 years of software engineering, I came to the conclusion years ago that most deadlines were entirely arbitrary. The business isn't going to fail if you slip a week, or frequently even six months and if it does its probably not the fault of engineering unless its so dysfunctional as to repeatably blow through its own delivery estimates. Sure there are regulatory deadlines, customer POC or delivery deadline…
> You cannot take a sick day by telling your team, “I have mental issues and need a day off.” Actually, that is exactly what you _can_ do. It just takes more transparent communication about your needs and desires and more trust and safety within you r company and team...
> You cannot take a sick day by telling your team, “I have mental issues and need a day off.” Actually, that is exactly what you _can_ do. It just takes more transparent communication about your needs and desires and more trust and safety within you r company and team...
You can but there's still stigma surrounding mental health in many workplaces
If we can even discuss my mental health, there's no way I'll be able to work there.
Earlier quoted context omitted.
Many people misunderstand this. Just saying 'no' and being firm won't make you successful, it's not a very useful. Saying 'no' while convincing others that 'no' is actually the best strategy is a great skill.
A good way to say "no" is, "yes, but then the thing I'm working on will not be done".
I think it is so important to be able to disconnect from whatever it is that we are doing, even for a very short period of time. Go for a walk, brew a coffee or simply close your eyes and breathe. Many times, stress is created artificially. It hurts our performance and deteriorates our ability to think. Encountered numerous situations where work was "urgent" and would likely land a contract or sales for the company,…
I've come to believe that there's something about the practice of software development that causes , or can cause mental illness. I've seen a few colleagues over the decades have some very serious issues. It's really quite a serious problem in our industry, imho.
Earlier quoted context omitted.
https://grugbrain.dev/#grug-on-saying-no > best weapon against complexity spirit demon is magic word: "no" > "no, grug not build that feature" > "no, grug not build that abstraction" > "no, grug not put water on body every day or drink less black think juice you stop repeat ask now" > note, this good engineering advice but bad career advice: "yes" is magic word for more shiney rock and put in charge of large tribe of…
It site is an amazing and hilarious encapsulation of pretty much every conclusion I've come to after programming professionally for 20+ years (except maybe generics)
I recently caught myself excitedly showing grugbrain to a younger dev, quoting the microservices section - and realized that I've come full circle, and now I'm the old bearded dev passing on some piece of thing that I found inspirational / exciting.
In almost 30 years of software engineering, I came to the conclusion years ago that most deadlines were entirely arbitrary. The business isn't going to fail if you slip a week, or frequently even six months and if it does its probably not the fault of engineering unless its so dysfunctional as to repeatably blow through its own delivery estimates. Sure there are regulatory deadlines, customer POC or delivery deadline…
It depends on the industry. Video games are still sold at retails stores (Target, Best Buy, ...). Those stores have to coordinate what is going to be on their shelves months in advance (6+)? So you promise your game will be ready and in a package and at their loading dock by November 15th. If you miss the deadline their shelf is empty of product since its spot was reserved for you. Other customer electronics have sim…
Earlier quoted context omitted.
Honestly, most companies and projects fail completely. In my 25ish year career I can only think of a handful of lines of code that I've written that are still in production (or that I think might still be in production) and only a few employers that still exist. When you pan out far enough it all seems a bit silly.
I think this is confusing code with output. If you work for a company that builds medical software, then your output is something like quality-adjusted life years for patients and has nothing to do with the code you incidentally use to get there. Taking the view that none of the software you wrote is still running is a bit like an automotive engineer who thinks none of the car models she worked on at the start of her…