I wasn't sure of this, even though sometimes you'd see remains of the original characters near rectangles edges.. does this mean the leaked documents have been de-redacted ?
Why would that be the case? The government isn't redacting "yes we contacted aliens" they're redacting information about military capabilities that might be of use to adversaries.
usually what i did is to take an abstract spec, derive thick layers / modules to decompose the problem, and then look at the deadline to see what MVP i can draw in that space.
whenever that mvp is not what was expected, if i'm lucky enough, the decomposition allows for easy adjustements to match the need
beware, some cultures are territorial in nature and this kind of hard ownership will make people slap you if you ever try to improve things as they come.
i'm in the camp of improving things regularly without hesitation but again this can devolve. another way it can turn sour is when the team is made of people too different from each other. one improvement from someone pov is a waste or even a regression for others .. then it's a 'who decides here' conversation.
that said when you have a cohesive group all focusing on pushing in the same direction then it's bliss
Then that's a bug in the organization. If you're senior enough you might make the correct boss take notice and signal this defect globally (no fingerpointing) to him/her. If they don't care or answer you know where you are now and know if you consider that you want to leave or not.
I did this by constantly complaining about JavaScript and how TypeScript is so much better until some of my colleagues started writing new projects in TypeScript.
If juniors ignore guidance and advice, they stay in junior roles, handling simpler, less impactful tasks.
Everyone seeks career growth, but pushing for it too quickly often just leads to inflated titles without real substance.
It’s perfectly fine to remain a mid-level engineer for your entire career if it makes you happy; it’s solid, honest work that contributes meaningfully.
Plenty of people in their 60s have held the same job for decades, and that’s okay; it can be a path to genuine satisfaction.
Hinging senior evaluations on junior promotions directly fuels the title inflation I’m decrying. Desperate to show “impact through development,” seniors (or managers) push for premature title bumps; turning fresh juniors into “mids” or “seniors” without the skills to match, just to hit metrics.
This is rampant in tech, where inflated titles compensate for everything from low pay to talent wars, eroding expertise and making hiring a nightmare.
We end up with a system that prioritises optics over substance, where growth takes a backseat to checkbox promotions. It’s frustrating and counterproductive.
Mentorship should inspire organic development, not force-fed ladders that collapse under their own weight!
Instead, let’s measure seniors holistically, decoupling from junior title escalations to allow people to excel at their level indefinitely. Alternatives include:
* Technical Proficiency and Individual Contributions: Use code reviews, technical assessments, or metrics like deployment frequency and bug resolution rates to gauge a senior’s direct impact, without needing to “graduate” juniors.
This focuses on their own output and problem-solving prowess.
* Knowledge Sharing and Enablement: Track things like workshops led, documentation created, or peer feedback on guidance quality via 360 reviews—emphasising team uplift without mandatory promotions.
* Project Outcomes and Efficiency: Evaluate based on team velocity improvements, innovation (e.g., patents or architectural wins), or overall delivery success, rewarding systemic contributions over individual mentee milestones.
These methods honour diverse career paths, letting juniors stay put if it suits them while still valuing (and evaluating) senior leadership.
Agreed, a direct metric of “promotion rate” is obviously flawed. I posed it more as a rhetorical question for reflection- at the limit, it’s clear that people with mentoring responsibilities should be accountable somehow for being good mentors. Terrible mentors who undermine, sabotage, or consistently fail their mentees definitely exist.
A lot of the comments are complaining about how this metric is a terrible way to evaluate seniors but I'd disagree. If one junior can't grow then it's a problem for that junior. If no juniors can grow then it's a problem for the senior - either they don't have good mentoring skills OR they need to work on improving the hiring pipeline for their team (either raising the bar in interviews/changing what skills you're evaluating for in interviews/working with recruiters to fix the pre-interview filters).
In either case it's an ambiguous problem that needs to be solved and just throwing your hands up and saying that you don't want to be evaluated for that is not going to help.
I've never worked at a place like that, and I hope I never do. Although, I've never even heard of any reasonable person putting that into practice either, so I'm probably safe.
> Any mentor type figure is going to be at least partially evaluated by progress of the mentees against some benchmark.
Sounds like the same kind of mistake as evaluating teachers by the grades of their students. Soon people figure out the "one weird trick" how to get the highest score easily.
> Everyone seeks career growth, but pushing for it too quickly often just leads to inflated titles without real substance.
That's why I'm not a big fan of recommending people to often and quickly change jobs to increase titles and pay. Their skills don't level up the same way, and they end up with a title of senior/lead developer and can't actually build maintainable systems or solve problems that nobody tells them the solution to.
If one is unable to work alone but manages to join a new company with an inflated title, people will notice. They're gonna have to keep job-hopping until they find a place that doesn't notice the bad performance anymore.
This is demonstrable by the amount of CVs with "12 jobs in the last 6 years" in my reject pile.
He is extremely productive in its specialty: the intersection of programming language and system programming. I don't think that makes him superhuman.
It's more a model of what a really talented person who applies themselves building things they enjoy building can do.
I prefer thinking of it this way: if Bellard can make a small JS engine from scratch by himself, what's really stoping you from knocking down this library you are thinking about.
These days it's not rare to have data center heated buildings. I guess crypto bros are just not thinking about this. But technically if could be done there too.
There was a startup in EU which explicitly sold heat from crypto mining to the local energy provider. IIRC it was also here on hacker news some time ago.
reply