Quality over quantity. I have seen people who have done things better and faster than a whole team. I am almost one of them but alas I only work for few hours before deadline. If I could work like this every day I would single handedly build everything. It kinda bugs me what stuff I could do if I didn’t suffer and delay it all feeling mix of guilt and shame.
It's called Brook's Law. It takes a lot of time and effort getting people up to speed, and that takes experienced devs away from coding. You also have to get them credentialed, teach them the tools, need extra code reviews/testing/bugfixes while they learn the quirks and pitfalls of the code base, etc. In the long term you'll be able to get more done, but it comes at the cost of short term agility.
Maybe "credentialed" wasn't the right word. I was thinking of software licenses and access to third party tools and systems. Probably not as big a mess in game dev as it is in government.
You mean you didn’t enjoy sitting there when your thumb up your ass while you wait 6 months for a background check and another 6 months to get your GFE? Crazy!
Yeah, it happens everywhere, all the time. And the main cause of it is, surprise surprise, people who have no technical understanding of the subject matter.
If you have a troubled project, and you add more people, you have a bigger troubled project.
It’s a common trap for project managers … and in fact some pretty high brow projects blew up because of this.
When you are called in front of the board, and they say:
“Hey, your project is late, we get it, it’s not your fault, but we have to deliver on the 1st of the month. - and so we’re giving you our 10 best men to get it done”
I can tell you, it takes a certain amount of testicular fortitude to say “That won’t work”. More than I had at the time , in fact.
My anecdote isn’t quite the same since it deals with something a lot simpler, and lower stakes than stuff like this.
used to assemble bicycles for a sporting goods chain, and had to travel to a nearby city to build theirs because nobody there knew how. I had two days to get 300 done.
I got there and start, and about two hours in the store manager comes over and tells me he’s pulling 2 of their operations employees to help and learn how to build. “they’re the strongest guys we have so they should have no problem tossing these bikes around”
I straight up told him I have no time at all to train them on how to build and do the safety inspections correctly, not to mention the fact that I will still have to personally inspect every single one they put together anyway, so if they want to give me help I’ll take it but they’re on trash duty. Remove all the packaging, put the bike next to my work area, toss the trash. I will build. If there’s extra time at the end I will be happy to instruct everyone in the store how it’s done. Or even put me on the schedule for next week to do it.
Dude got pissy and wanted me to train people first, so I just called the district manager while he was talking and had him tell the guy to do what I said because I’m here at corporates request and if I don’t get the bikes finished in time then “it will look bad on your store’s next visit if the bikes are still boxed up”
In the end I got all of them done with about 3 hours to spare, so I spent the rest of the time teaching a couple people how to do it.
More like 12-14 hours, and with the experience I had I was able to build most in about 6-7 minutes.
There’s downsides to speed building like that, because whoever has to inspect it when it gets sold has to spend a lot longer fixing minor problems.
If I were building at my own store, each bike took about 20 minutes because I made sure everything was as close to “ready to ride” as possible.
Nowadays I bulk build for many companies. They don’t give a shit about quality but I spent years making sure my bikes were perfect, so I still like to make them good to ride out the door.
my quickest bike was one particularly well put together model. 3 minutes per bike and it was good enough that I’d ride one without tools to the nearest store a few miles away.
Big teams are faster on straightaways. Small teams go through the corners better. Upgrading from a go-kart to a dragster may just send your project 200mph into a wall. Sometimes a go-kart is really what you need.
Currently in a project, where for strategic and unrelated reasons, we ended up with 4 new juniors and had to hand off one senior. In a team that consisted of merely 3 people before.
So, it’s just me and another guy having to constantly juggle these juniors to push them back into the right direction and review whatever code they ended up with.
It’s so frustrating, because while I’ll gladly pass on my knowledge, the project has basically ground to a halt.
There’s so many tasks me and the other senior would like to just quickly tackle. Which should just take a few days, no big deal. Oh no, I rarely get a day’s worth of work done in two weeks. The rest is just looking after the juniors, who cannot tackle many of the actual crucial tasks.
And it’s not even like the juniors are doing a bad job. Frankly, they’re doing amazingly for how little support we can give them. But that doesn’t stop the project from falling apart.
My commit messages have gotten extremely lazy since I start squashing all my commits down to one. I just describe the PR on the first commit message and write nonsense in all the others.
I know that if you are on the local repository where the commits were originally created they’ll remain accessible through recovery methods but AFAIK orphaned commits aren’t synced to other machines.
That’s correct. This is for work, which uses GitHub. The dangling commits remain accessible via their sha through the web ui, so I can link them in the PR description. I don’t put them in the actual commit message.
I think these are garbage collected eventually, but no idea on cadence. It’s long, anyway.
Spring singleton beans are supposed to be stateless though, so they can’t be called variables. Maybe the DI aspect of Spring is less relevant today in the micro service era, but in the day Spring helped make layered monolith apps much cleaner.
Really? From my experience the opposite is the case. I work on a smallish team with 3 other developers and we also have a few spring services with < 100 classes and we constantly run into issues where making changes to a bean causes issues in another unrelated part of the codebase. I can’t imagine what a nightmare it would be with a larger codebase and more devs working on it.
I didn’t have to program this, thankfully. The code was used as an example of recursion but the explanation was lacking so I ended up writing out each frame by end until I understood it. Took a few pages and a couple of hours.
I am grateful that I learned what I did going through it but I’d rather not do it again.
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.