It drives me nuts for example that discourse has "achievements" to distract you. Every discourse forum I join for customer service is yet another 15 distracting achievements begging for my attention. It's not that I care about the achievements, it's that it's the same notification system that I got a new message so I'm compelled to go see if the highlight is a new message and when it turns out it's not, it's a dumb achievement badge then my time has been wasted and my mind has been distracted.
Multiply this by 50 apps to 100 apps/sites etc and it's clear that features as such that can't be turned off are irresponsible toward and disrespectful of users. That idea that you're a bad person if you design and create such distractions needs to spread.
Of course it will be a decade before everyone updates to a version that supports this option and allows the user to enable it. In the meantime we'll have our time and attention wasted for years (T_T)
There's another, automatically getting spammed with emails and then having to manually opt-out. I get you want it to be frictionless but when signing up a opt-in checkbox for email would respect my time and scarce attention than opting me into daily emails and forced me to later opt-out.
And sorry to pick on Discourse. There's tons of other offenders but Discourse is one most people on HN have experience with. Steam/Xbox/Playstation all have the same issue. Wasted time and attention required for things I don't care about. The worst is the OS popping up achievement notifications right over the climax of some scene. That others care is fine. Just let me turn them off because "Attention is your scarcest resource".
As a user, I don't want to be bombarded with distracting emails and notifications every time I join a new board.
I've been doing that for youtube to block video thumbnails and it works really well for me.
In my experience it takes six or more people to fully occupy a manager. Ten seems to be about perfect. You can go higher than that (and many do) but at a certain point you’re not evenly investing in all your people anymore, you’re mostly focusing on a few at a time.
Obviously the hardest part of this is if you don’t have 6+ people to manage. My answer to very small teams is not to have a manager at all, just have a technical lead and trust that a group of 1-5 people can work out their own crap.
I figure it's only a matter of time before I'm let go. Five years of equity down the drain, but I've already tried to fix the situation and upper management just doesn't care. The new CTO doesn't know me well enough to care about the past, when times were good.
Another lesson hard learned was realizing it’s not my job to do everything like an IC. And especially not my job to personally fix all people problems. I’m merely just here to guide and coax along the right path. And give lots of specific feedback on what’s good and what’s not so good.
A hope maybe this helps the grandparent poster. Your post resonates heavily with where I was at a year or two ago. Being a manager ain’t easy. I’d argue much more so if you were a really strong IC.
I've known since university I'm bad at delegating things. Do I just have to learn by doing it?
Finally, what do you mean by IC? I'm pretty sure I'm not an integrated circuit, but I've never gotten the head X-ray to check for sure.
Another topic might be communicating the lack of bandwidth for the work. Maybe there’s scope creep or too much work on the plate and some needs to be dropped.
As far as learning delegation, yeah, that’s how I did it: trial and error. For me finding really competent people who I trust and who want opportunities to grow and take on new responsibilities has helped a lot as a kind of prerequisite.
And yeah sorry IC = Individual Contributor, i.e. not managing anyone.
Second, since you’ve presented this to upper management and they aren’t understanding, I’d take that as a serious signal to look for a new opportunity.
If you do want to stick it out, the best advise I have for you is to 100% drop coding even though you think you can’t. Allow yourself to whiteboard, pair program and review PRs, but don’t allow yourself to be the owner of single programming ticket.
Suddenly you’ll have a lot of time to pour into training, equipping, and leading your team. You’ll probably be surprised how much they improve.
It still might not work out, but given you already know how to be a programmer, taking a shot at 100% managing for a while gives you more opportunity to learn than sticking with the status quo you’re saying doesn’t work.
If you’re really struggling and would like more help, I’ve been doing some coaching lately and I’d be happy to book a chat. My gmail is the same as my HN username :)
Maybe I should have gone the teaching route, I'd have other people to blame. But a good manager should protect their employees, not the other way around.
Thanks for listening. I guess I'm just complaining on a throwaway because I don't have anyone else to talk to.
Good software engineers are not necessarily good writers, so even when there is documentation it's not always helpful either. Especially to completely new people in a project without background information. For security related work, how much background can you assume? How in-depth does the documentation have to be? etc etc..
Documentation, even when it's there, doesn't always fix this.
My employee number is under 25, but it's still just pretend equity at this point.
A. What is the value of your equity?
B. What is the likelihood of it vesting in the next 5 years?
C. How much "total benefit" (salary increase, stress decrease, etc) would you gain from moving to a different company over the next 5 years?
If A*B < C, move.
Heck, even 5 years might be too long of a consideration here.
Source: How Google Sold Its Engineers on Management https://hbr.org/2013/12/how-google-sold-its-engineers-on-man...
The more I move away engineering, the more I feel the unreliability of human beings, and its stark contraction to machines.
Of cuz, machines, when sufficiently complex, becomes unreliable as well. But by operating still within that boundary, one can already do exceptionally things.
People managers essentially are dealing with a completely different entities than machines. Rarely one can operate on 2 different entities and still perform exceptionally.
Ultimately employees move the company machine, whether their job is to code, sell, manage, or clean toilets.
Aha, so it takes one full-time manager to manage one 10x programmer ...
In all seriousness, is it time to get rid of the 10x meme? People have strengths and weaknesses; people have areas they've experienced before and things they've never done. Some people are going to work faster than other people on certain tasks - that's life.
Nope, you can't reduce the differences between people's skills into "they had more years of experience with X (but fewer with Y)".
First, there are people who spent decades working with the same technologies, and still somehow failed to learn the essentials. Some people simply have almost zero curiosity and zero desire to self-improve. (Giving specific examples is risky, because they sound completely made up. An Oracle database expert, who doesn't understand the necessity of having a primary key? A Java developer who never heard about Map, so he kept implementing it over and over again as a set of methods, for each variable separately?) Being 10x more productive than these people is quite simple. But it is also possible to be 10x more productive than the average developer.
Just consider than "10x more productive" doesn't necessarily mean typing on the keyboard 10x faster. You can save time by using a library; this includes understanding and using the standard libraries instead of reinventing the wheel. You can save time by using the right abstraction, instead of copy-pasting all over the code. You can save other people's time by documenting the code you wrote. You can save testing time by writing unit tests. You can save everyone's time in the future by having a clear project architecture. -- Furthermore, you can increase the team's productivity by teaching your colleagues at least the basics of these skills.
There are people who are this good at the things they do regularly. (Which also happen to be the things I do regularly, so it is humiliating to see the level of skill I will probably never reach.) And they can still learn new things with at least the same speed as anyone else around them.
Neither of those examples surprise me that much. It’s not that uncommon that being able to produce something that vaguely works well navigating a messed up organization is what it takes to be productive. The bar on not being a totally messed up organization is low but tons of places don’t clear it.
...otherwise - being a bit of a history nerd - I’ve run into the idea many times in discussion of how military units have evolved over time. Much of the thinking about ideal squad sizes began in WW2 - don’t have single thing I can point you at though
From my professional experience, it’s obvious that there are coworkers that can output even 100x impact qhen compared to peers. When judging entrepreneurs it’s visible some people’s multiplier/productivity is in the million-times compared to others.
Given automation is at the core of our work as devs, why do some people think 10x isn’t credible?
In my experience it's a lot more common that I see people churning out 10x the AMOUNT of code (or some other insane metric) which generates an enormous amount of work for everyone else to keep up with, fix, maintain, understand, etc. These people are praised for their output. But are they making the TEAM 10x more productive? No way.
Prolific output doesn't always mean 10x value created. I know people know this, but I think the reason people are sick of the trope is because they've been burned by a "10x'er" that was all output, not actual value.
Producing 10x value is actually.. really, really hard.
As a practical example, consider 4 people beating Windows Mobile with what later became Android.
They did this by breaking systems (DNS, build pipelines, etc), producing code so bad that it had to be rewritten from scratch, and distracting everyone on the team through drama.
They also did it through endless requests for help - not the kind where they learn from it, though. The kind where they ask the exact same question next week of someone else. They would cycle through asking everyone on the team about the minutiae of their job, because they had no idea how to do it themselves.
I realise that the idea of the '10x rockstar' is an unpleasant one. But I also know that the best people I've worked with over the years were at least ten times better than the worst.
Let me add that I enjoy teaching folks, that I enjoy being a multiplier even if it means I won’t be an additive. I am also an apologist, and willing to believe that people are adding important ingredients to a team or output that aren’t immediately obvious or visible.
But -x folks exist.
Unfortunately the -x folks often DO have significant skills at hiding their negative impact.
Any who remain employed, while being persistently -x (or -anything) would have to.
Especially in many mega-big organizations, in non-dev depts, the "Manager" is also tasked to: build and perform analytics, do VERY HEAVY ad-hoc reporting (aka Directors bombarding you with 10 different mini-projects weekly) and at the same time you have to run the projects with 5-10 people, meaning driving the ship, having huddles, handholding, coaching, mentoring, reviewing, be present in 40% of the meetings, etc.
I don't know how much hands-on is a programming 'boss' of 10 people. But if it's no coding at all, I am happy for you and I wish the same for me.
Clicks on link
You have to time-limit distractions.
I think we are going to find that attention is dominated by working set memory, and people who can juggle even twice as much stuff are going to operate fundamentally differently than those who can’t afford or won’t have the surgery. And past 5x it may become difficult to even communicate, much less compete.
rs17070145 in KIBRA/WWC1
Also, this was done with very low-resolution genotyping. Even if it's a genuine association, rs17070145 is probably not the causal variant, just something which is in linkage disequilibrium with it.
I would be careful equivocating working memory, attention and processing power. Attention is much more complicated than what one can juggle in mind actively, what is chosen to enter and leave it also matters, just as the shape and form of the task it conforms to. There is no singular unit in brain that “creates” attention, it is best thought as an emergent property of several, if not all, parts working together.
Besides that, even if we assumed a von Neumann architecture for human cognition, an increase in memory wouldn’t have expanded total processing capacity unless it was starved of it. I don’t think that is the case for humans, if there was a selective advantage to having more working memory as general problem solvers, we would have had it already. Granted, the types of tasks we undertake today can be different in shape, but not completely; still need to survive a physical world, still need to have successful relationships, still have to manage emotions, still have to do all of these while doing our specialized abstract cognitive tasks.
Although your argument of "if it brought such an advantage, we should have evolved into it by now" does hold water too. I suppose it hinges on how much of an evolutionary advantage we actually have from excelling in the kind of deep abstract thinking that some jobs require nowadays, vs. how much this improvement would've been worth in past centuries.
There are clear reproductive advantages to distraction. If your actions prioritize your own wellbeing (or the furthering of some cognitive task) over the instincts to eat, reproduce, and protect your children, your genetics will be at a disadvantage.
Once I get into a deep work state, the ability to hold and reason about more of the problem would definitely be helpful.
This dependence on short-term memory is why I find Rust's borrow checker intolerable during exploratory programming. Whatever coding bugs it prevents have to be strongly outnumbered by design errors it causes by stealing attention from the most critical activity at that time.
The borrow checker would deliver 100% of its value if it limited its enforcement to release builds, and just reported numbers otherwise.
Removing agency from users of your program or programming language is not a recipe for success.
I don't agree with you on this issue or your "recipe for success". The reply was fine.
You have introduced yourself, and I promise to remember.
The easiest way to "get around the borrow checker" is not to use Rust at all. We have evidence of people using it, so they are proof positive that not everyone will "just take that route".
If you meant not everyone, but some people, then yes, we know there are people releasing programs not coded in Rust, many quite successfully.
With such advanced devices hand-held already, why would we even need to interface with the human mind? If we're at the point of human-computer interface, which is probably 100+ years away, we will already be beholden to 100 more years of innovation in mobile devices, which is hyper-charged by capitalism already.
Think back to 2000: Very few people could have imagined the vast implications of these simple hand-held devices. It's much easier to make a hand-held, rectangular, "multi-tool" computer, based on existing tech, than creating a new class of technology to interface with neurons and store biological data.
Now, these simple "phones" have destroyed entire industries, created entirely new ones, allowed the scaling up of all kinds of mis and disinformation, and allowed the capture of human attention on a massive scale.
How many people in the rich world do not have a phone? How many poor people are trying to get one? How many times per day do people check their phone? How long do they use it?
We have all enrolled in a massive psychological experiment, something evolution or society as we built it never had to contend with. The "singularity" is coming and our devices are opening the door to it day by day.
I think part of the problem is that almost all software is designed to be usable without training/learning, so almost all task management tools get reduced to lists - which are inefficient.
We need a tool that retrains our brains to generate units of work that, aside from a line of descriptive text, also contain: NPV, value-over-time, hierarchical dependencies, resource allocation, location dependence, etc... ...and then have a simple piece of software prioritize based on calculated optimized order of action.
A PIM application ecosystem with a storage and RPC system like Newton soups (but updated to Internet security paranoia), stored in an open, highly-parseable format like Emacs Org Mode, with the enormous tweakability and context-sensitivity of DateBk6, combined with the dynamism of LifeBalance, would be very interesting.
Looks like it's just a heavy cube to use as a fidgit toy? I wanna play with it now too lol.
Edit: I don't know how to link directly to a single amazon review but holy shit read the one from Richard , it should be the first https://www.amazon.com/Tungsten-Cube-1-5-One-Kilo/dp/B00XZBI...
I have carried the tungsten with me, have grown attached to the downward pull of its small form, its desire to be one with the floor. This force has become so normal to me that lifting any other object now feels like lifting cotton candy, or a fluffy pillow.
If you have the extra money and you are attracted to the idea of a basic shape with strange properties, I would say you should get it.
I hadn't realized that I probably keep way too many "open-loops" in my life. And they are draining away my attention-currency.
Last night I finally cleared off all my emails and did all the little task that have been sitting around. It feels so good to not have them lingering on the edge of my brain.
The built in blocking with downtime is nowhere near granular enough, and it is rather easy to turn off. Do any third party browsers or apps have schedules for viewing certain sites?
Eg on mac I have an app, coldturkey, which blocks certain urls during the workday.
I can undo these things easily enough, but it's sufficient that my monkey brain can't just open a tab and go there without my conscious permission ( which disturbingly is how habit forming these sites are for me.)
I keep them available on my mobile, but I have an old, slow phone and I never keep it on my desk, I put it out of reach and with notifications on silent.
For things like Facebook and Instagram my solution is simply to delete my account and never let that abomination steal precious minutes of my life. I don't miss them at all.
Something I've done is bind a key that changes my top-level key map to a pared down version that only has meta, a command to tell me the time, access to my music controls, and a way back to my main key map. Of course I can still get to anything on my computer with just a little effort, but the additional friction is sometimes useful for staying on task.
Anything that introduces enough friction that you stop and make a conscious decision will do the job.
Edit: nevermind, found it. You configure a custom id on their site, then enter that in the app
There aren’t any scheduling features, correct?
Especially because those 3 are unlikely to come back.
Part of it is trusting that future me can get it done properly. A trusting partner with which to delegate the task to.
I recently transferred to a team with an explicit intent for me to be an EM on that team. A few months down the road they said I wasn't meeting expectations because of my "time management" which had too many meetings and lacked focus time for IC work - which definitely was not my 50%+ focus. I'm "winning" the resulting political war (my last 1:1 left my lead in tears), but only in the limited sense that I'm not getting fired; it's been a bit of a disaster for everyone.
The unclear expectations of what gets someone an EM role and what is expected of that role is the root of my problem, some of the author's, and a lot of the industry's as a whole.
Leaders are picked from those that are truly focused on tech and truly excel at it... and then told not to do that. How can somebody be "intuitively, emotionally invested in the outcome" of tech work and then suddenly be expected to stop doing it?
I should have been that rare counter-example in that I got picked for this role because of my very visible leadership in other areas. However, when it came time to give me the position formally they fell back on code output and found it somewhat lacking (specifically, the number of commits I made while onboarding was less than those of my established teammates).
There's a school of thought that switching back and forth between IC and EM tracks lets you build a lot of knowledge and be both better manager and IC (the author evidently did). While I do think experience with each helps you do the other, there is a cost to that focus shifting. This isn't like the cost of only being able to code in 45 minute blocks. It's the cost of shifting the things you care most about entirely.
Most managers fail to ever make that shift. Even if they manage to hold themselves back from coding (not all do), their heads remain in the code. One sign is when, in response to impossible expectations from above, they try to come up with technical solutions (e.g., if only we redesigned this module we could meet these impossible deadlines). If your mind is focused on tech, it's the tool you use to solve every problem. Another example is when team members have no idea how to move their careers forward and don't know expectations. A tech focused lead won't be thinking about how a new project is actually the perfect challenge for a more junior employee; their head will be figuring out the best way to solve the task technically.
An EM is not a tech lead. It's not just a different skillset, but a mindset change.
Wow, I never heard it articulated that way, but that’s exactly what it is. In 2015, after dodging the EM role for half a decade, my manager left, and there was no one else, so I had to step up. I was below average because I never stopped caring about the code. Luckily for my team, I left the company after eight months.
Now, having been the senior tech person in a startup for the last four years, I feel the fatigue from churning out code (I’ll sketch out a design over a few minutes, and then have to spend days building it), and it’s obvious that the only way to get a better ROI on my time is to lead and/or delegate. For the first time in my career, that feels exciting. I still care too much about tech to be a good manager, but I feel my mindset shifting.
Sounds like some of your coworkers thought an EM role was [a lead developer], which it is not. As a manager, being an IC leads to a bunch of structural problems with the code and therefore the team.
Even if you make it a separate track, it's hard to define what the promotion looks like for more senior engineers, especially at successful companies. When you have $2M of cash in the bank thanks to stock, does a 10% pay bump from senior to staff matter? Does the title bump matter? How can you reward a long-standing successful senior engineer in a way that seems meaningful?
This isn't a question I have an answer to, but "make them a manager" is definitely the wrong one. The majority of my managers have told me how jealous they are that I get to code all day. More than one has told me straight up they do not want to manage. I've watched several teams implode under managers like that.
I think it's completely valid to not want to manage. Hopefully your lead doesn't pressure you to take such a role in the future. But have you thought about what success would look like in your career otherwise?
It is also valid to not be particularly ambitious, to enjoy the craft of software engineering until you retire, and spend the mental energy you would spend on getting promoted on hobbies, family, advocacy, or whatever else brings value to your life... though it can be hard for those of us who are more ambitious to realize that.
I had a boss who was being weird about making me a lead for the first time. I needed him to make it official, not fret the title. I told him I didn’t care what he called me as long as people did what I asked them to do.
If you want to stay an IC, I can not recommend loudly enough that you learn to manage your finances and your consumption. Managing your “needs” makes your savings last longer. Getting a raise just lets you build your savings faster, which might not be the same (especially since your needs will be inflation adjusted but your savings will not).
It’s harder to maintain the courage of your convictions when you are in debt than when you are doing okay.
If someone makes you work for a promotion, they are manipulating you. That could be good (in a mentor) or bad (in a labor exploiter). But you are being manipulated, and it’s better if it’s really your choice, not your mortgage or your kids’ braces.
I initially didn't care about titles, but they do constrain what work you can do. The reality is that if your title is one of an individual contributor, even if you lead culture change at the company level, they will always look for the code. If they don't find it, you will be in trouble.
One thing I have learned over the last year of my life is that being "Shadow lead" - the one actually pulling the strings and making things happen, with no formal title/recognition - is the worst spot to be in. The work you are doing doesn't match what you should be doing on paper, so you are very vulnerable if somebody decides to take a closer look.
It's "glue work" but on a larger scale. It's important, but will go unrecognized. It's emotionally exhausting to build a team and get a head pat and told someone else will lead that now, thanks, and by the way how much code did you write recently?
Though I do wonder what you mean by "official" but without the title. It might be the case that "everybody knows" what you do, but if your lead is replaced or just changes their attitude, suddenly your IC work is under the microscope, and could be found lacking.
If the software team is of a medium size, let's say, less than 50 people, then it surely isn't how you paint.
The CTO / Manager(s) for sure know the impact of the ICs and likely nobody is measured by LoCs. I personally have never worked in an organization (10 companies and counting) where LoC has ever been mentioned as something being measured.
Though that was the stupidest way to come to that conclusion, it is true that I was doing less IC work than other members of my team. I had surfaced this several times in 1:1s and thought that was what he expected. For instance, some weeks I had literally 20 hours of meetings, with significant overhead attached to those; it is hard to make much progress coding in that environment.
Of course, your best bet for achieving these goals would be to spend less time reading HN and more time actually "Doing the Work".
You're so right though. It is the allure of potentially finding a silver bullet. Combined with the great community and thoughtful discussions.
Like a move baddie saying, "Trust me when I tell you: Don't trust anyone" <- this the bad guy right here. You don't need to watch the rest of the movie.
TLDR: If you value your attention and want to respect the intention of the article, don't read it ;)
- Asanga, from Abhidharmasamuccaya
> As a manager, it became impossible to “only work on one thing:” there were too many small tasks and too many projects going on in parallel.
As someone with ADHD, thank you for that reminder.
It is an obvious issue that is hard to be aware of.
If you can’t do either then you have to treat it like a priority and not something that can be time boxed.
Ha. I hope said friends are not reading his blog.
I say that as a massive luddite in this regard, I hate always-on culture. But I learned you have to make some concessions, because your friends will use what's convenient to them and the harder you make it the easier you disconnect them from you. Real friendships aren't built in a day, and you'll be stifling every relationship you try to build if you don't meet them half-way.