Mockito, in every case I had to use it, was a last resort because a third party library didnt lend itself to mocking, or you were bringing legacy code under test and using it long enough to refactor it out.
It should never be the first tool. But when you need it, it’s very useful.
For a UX pattern, I will often need to move multiple items at the same time. I'd like an exploration that allows the equivalent of shift-click and command-click for multi-select. And if they're not consecutive, they should be grouped.
Otherwise, it's going to be a very frustrating experience to move a number of things.
One is a "one junior per team" model. I endorse this for exactly the reasons you speak.
Another, as I recently saw, was a 70/30 model of juniors to seniors. You make your seniors as task delegators and put all implementation on the junior developers. This puts an "up or out" pressure and gives very little mentorship opportunities. if 70% of your engineers are under 4 years of experience, it can be a rough go.
That second model is basically the hospital model.
You have 1 veteran doctor overseeing 4 learning doctors. For example operating rooms do this, where they will have 4 operating rooms with 4 less experienced anesthesist and then 1 very experienced anesthesist who will rotate between the 4 and is on call for when shit hits the fan.
Honestly I think everyone here is missing the forest for the trees. Juniors their main purpose isn't to "ask questions", it's to turn into capable seniors.
That's also why the whole "slash our junior headcount by 3/4th" we are seeing across the industry is going to massively, massively backfire. AI / LLMs are going to hit a wall (well, they already hit it a while ago), suddenly every is scrambling for seniors but there are none because no one wanted to bear the 'burden' of training juniors to be seniors. You thought dev salaries are insane now? Wait until 4-5 years from now.
Fred Brooks proposed "surgical team" structure, where as people gain experience they "bud out" new teams - i.e. the most senior after "the surgeon" ultimately leave team to become "surgeon" of a new team
I guess Peopleware couldn't get every single thing right.
A hospital model may be a good idea. One where you have a senior programmer and many junior ones doing most tasks isn't. IMO, something closer to a real hospital team, where you have experts of different disciplines, and maybe a couple of juniors composing the team has much higher chances of success.
> something closer to a real hospital team, where you have experts of different disciplines
That is not how hospitals work. The surgery departement won't have a crack team of different disciplines to teach budding surgeons everything. They'll only have veteran surgeons to guide less-experienced surgeons.
What you will have is interdepartmental cooperation / hand-off, and you'll have multi-discipline roles like surgical oncologist.
In the same way, you won't have devops seniors training front-end juniors.
A surgery team has a surgeon an anesthesiologist, a nurse specialized on material handling overseeing the material usage in the procedure, maybe a nurse specialized on equipment handling. None of those people are junior or subordinated to the others.
In my operational team, I'm following a third model, inspired by german trade workers. You have juniors, journeymen and masters. Juniors are generally clueless and need to be told what to do, specifically. This is very much the level of "Here are 28 marks that needs bolts placed in concrete, make it so, I can explain why". Journeymen should be figuring out a plan how to solve a project and challenge it with the master to see if it fits the quality requirements of the master.
And practically, you can have one or two journeymen per master. However, these 2-3 people can in turn support 3-4 more juniors to supply useful work.
This also establishes a fairly natural growth of a person within the company. First you do standard things as told. Then you start doing projects that mostly follow a standard that has worked in the past. And then you start standardizing projects.
My first big job was the 1 junior per team; those years were extremely good for learning how to design and write high performance services. Since then, I've mostly been at the 70/30 places where I'm considered senior. Occasionally I just sit down and blast out a big software project, just to feel I am still able, but mostly I tend the garden hoping that a few of the fragile stems will survive and grow into mighty oaks.
With the subjective view on what a junior is, I think the 70-30 - or higher - model is used in any company I ever interacted with. For this evaluation I consider junior=someone with less skills than needed to do the job autonomously/require direction and supervision most time, senior=someone that can work autonomously.
This was at the beginning of game design. Everyone was still learning what good game design was and it kept changing as the technical constraints changed.
Just remember that the market can stay irrational longer than you can stay solvent.
Consider diversification in your portfolio. Maybe you divert a little more away from the US market, for example, which is heavily dependent on 7 stocks largely tied to AI.
Also check how diversified the instruments you choose are. Sometimes they are lot less than one will think they are. Mainly due to those 7 stocks being big component in them also.
There are a wide number of small problems for which we do not need bridges.
As a stupid example, I hate the functionality that YouTube has to maintain playlists. However, I don't have the time to build something by hand. It turns out that the general case is hard, but the "for me" case is vibe codable. (Yes, I could code it myself. No, I'm not going to spend the time to do so.)
Or, using the Jira API to extract the statistics I need instead of spending a Thursday night away from the family or pushing out other work.
Or, any number of tools that are within my capabilities but not within my time budget. And there's more potential software that fits this bill than software that needs to be bridge-stable.
But the person I replied to seemed to be talking about a task agenda for their professional work, not a todo list of bespoke little weekend hobby hacks that might be handy "around the house".
You assume they were talking about a single product. at my job there is essentially endless amounts of small tasks. We have many products and clients we have many internal needs, but can't really justify the human capital. Like I might write 20 to 50 Python scripts in a week just to visualize the output of my code. Dead boring stuff like making yet another matplotlib plot, simple stats, etc. Sometimes some simple animations. there is no monstrosity being built, this is not evidence of tagging on features or whatever you think must be happening, it's just a lot of work that doesn't justify paying a bay area principal engineer salary to do in the face of a board that thinks the path to riches is laying off the people actually making things and turning the screws on the remaining people struggling to keep up with the workflow.
Work is finite, but there can be vastly more available than there are employees to do it for many reasons, not just my personal case.
Why? It turns out that I try to read people who have a different perspective than I do. Why am I trying to read everything that just confirms my current biases?
(Unless those writings are looking to dehumanize or strip people of rights or inflame hate - I'm not talking about propaganda or hate speech here.)
Personally when I go to the grocery store I pick fruits and vegetables that are ripe or are soon to be ripe, and I stay away from meat that is close to expiration or has an off putting appearance or odour to it.
Louvre get sort of boring, since the time period they cover stops at the time when art gets more and more interesting (mid 1800s). Before that every painting is basically Jesus or boobs.
This year they made a brilliant thing: they put haute couture one-off fashion items on display throughout the royal wing.
Who knew Loubutin and Alexander MacQueen shoes or Dior and Gucci handbags would feel so absolutely natural among the dresses and tapestries and jewellery :)
Other than the theme, what's the difference between typing what you want into Slack and maybe getting it can typing it into ChatGPT and maybe getting it?
It should never be the first tool. But when you need it, it’s very useful.
reply