61–70 of 545 posts
> when the Agile meetings at my last job got so absurd that we were being asked to estimate JIRA task time in T-shirt sizes Feels like a very outsized reaction to have to something well-intentioned, useful, and not-ridiculous.
It's quite ridiculous for a number of reasons, well documented by research and experience: software engineers can't estimate how long something will take with any kind of accuracy.
Earlier quoted context omitted.
At a level or two down from the abstraction of company size, crafting hobbies are also a reprieve from the tyranny of linters. So many programmers today believe that code is always better when it all looks identical. Consistency is a good thing, but not when it's expected to be absolute. Programming should actually allow for creativity, and where you decide to add spaces and newlines can actually add subtle but impor…
Consistency is critical for reducing mental load when working as a team. Format your personal projects however you want, but when collaborating your editor should apply the standard format every time you save.
I absolutely agree that consistency, in principle, is usually a very good thing.
My objection is to the idea that it's always a good thing, which it's not. Treating code formatting as rules rather than suggestions, in my experience, is a waste of time and unnecessarily tyrannical.
In terms of mere code formatting, I don't buy that there's a meaningful difference between 100% consistency and say 95%.
It's far more important that APIs and other conventions are consistent. When constructs in the code aren't consistent, it can be an absolute nightmare. When code isn't formatted well, it's usually just annoying and can be trivially fixed with automation.
Earlier quoted context omitted.
The reason it failed in prod was entirely unrelated to it being prod. The same could have happened in staging. IIRC, the error was entirely due to a RST packet from some external system during the upgrade. It was a bug in the upgrading system that should have been accounted for, had anyone known it existed. Identifying the root cause of the failure, was what took the most time. Had deployments been idempotent it also…
Sounds annoying, but seems like you found a bug in the upgrading system that could have struck anyone during any change? The time/work to investigate and fix it probably wasn't considered (or shouldn't have been, at least) part of the work on the component you were changing - that was just delayed, same as it would be in scenarios like "Dave got hit by a bus and he's the only one with the prod password" and "Our CI s…
I have to laugh because I find almost all programmers are like this. They are almost always people who like making things. A lot of them are musicians too. I find DIY to be similar - you get a physical result, you use your hands to make something, the satisfaction is almost always about pleasing your own sense of what you want. Ok there's the wife too but .... I also like feeling that I can cope with certain jobs eve…
I also find cooking (not necessarily baking) to be quite similar to programming: you follow steps and if some bug happens in production (too salty, too thick, not flavourful enough) then you go in and try to debug it and fix it (I guess the simile breaks down here).
But if someone is good at breaking down IT tasks, I believe they will be able to prepare a large meal with multiple courses, as I find it requiring a similar mindset to releasing a feature.
I am working on coding stuff I like as escape for the absurdity of modern software. I make little games, stuff for 8 bit systems etc. Stuff that is as far away from anything modern , especially the hell of node, next, devops and ‘web frameworks’ as I possibly can. It works. It’s very relaxing, like a bonsai tree.
I wonder whether we’ll see the same parallel as with cars: those with tech and those without - old-timers. I only code as a hobby anymore. Burnout destroyed my career and now I design PCBs and write embedded software without LLMs.
Earlier quoted context omitted.
It's quite ridiculous for a number of reasons, well documented by research and experience: software engineers can't estimate how long something will take with any kind of accuracy.
But that's exactly why people start using things like t shirt sizes: to emphasise the point it's not a time estimate. It's a rough ordering of relative complexity of different tasks, which is something programmers can do. Of course, the business still needs time estimates, so someone will somehow attempt to turn them into time estimates. But that can't be helped.
Yeah, when put as an estimate of effort or complexity, we can be good at estimating that. But that isn't how it was put.
> so someone will somehow attempt to turn them into time estimates.
It works until it doesn't. I would estimate manually entering data as "pretty easy" but it won't be done in a day no matter how much you pay me. I can only type so fast. There are many tasks that are easy but take a really long time, and many complex tasks that take a very short amount of time.
Earlier quoted context omitted.
At that point, you are estimating EFFORT, not time. Software engineers are REALLY GOOD at estimating effort. The fact that they translate to time (simple == several days) is ephemeral.
I think that is how Agile is suposed to work. The programmer stimates how hard the task is relative to other task he has done.
I worked at a bar when I was young, listened to the stories; the most annoying protobuf deserialization issues or 'Agile meetings' are freaking fun compared to the most of the stories you can hear.
This is just comparing apples to oranges. Woodworking or any other hobby that you enjoy will be more pleasing than any real job you will do. Programming is fun, that is why you started doing it. Working as software developer can be less so.
Earlier quoted context omitted.
Consistency is critical for reducing mental load when working as a team. Format your personal projects however you want, but when collaborating your editor should apply the standard format every time you save.
Maybe I'm not articulating my point very well. I absolutely agree that consistency, in principle, is usually a very good thing. My objection is to the idea that it's always a good thing, which it's not. Treating code formatting as rules rather than suggestions, in my experience, is a waste of time and unnecessarily tyrannical. In terms of mere code formatting, I don't buy that there's a meaningful difference between…
What I absolutely detest, is any kind of code formatting comment on a PR. If it cannot be enforced automatically, it’s not worth arguing about, and definitely not something to hold a PR up for.
Most of the people I know who pursue creative/crafting hobbies alongside a software development job have chosen to work for well-known big companies, for prestige and safety, and ended up unfulfilled in their jobs. Most big companies are not good if you want to solve problems and build stuff. Especially "the enterprise", where software is seen as a cost center so the less of it the better. The effort of managing up e…
I learned to play the game. I too really enjoy being able to talk directly to the client while building, but I also learned to play the game of cogs, where I am separated from the client by layers of increasingly clueless management. I balance the insanity with pursuing photography.
I work for a large company , and I love people I'm with and had some great challenges and accomplishments, but yeah... There's still a creative urge that's left not completely filled. So I ran a photography business for a decade!I loved interacting with happy and involved clients, and creating something that brings them immediate joy :). I don't have time anymore to do it professionally but I still do it for friends and family ( while I work with my therapist to survive my day job :)