IMO, someone’s tangible value of putting an Ape as their avatar pic on social media might be greater than that of someone being able to use a ship purchased in Star Citizen.
It’s a little crazy to me how Twitter profiles with Apes are viewed as “influencers” and “pioneers” and get treated as such. Not my cup of tea per se, but there is tangible value for some people there.
This! I prefer 80 characters so I can have two panes of code side by side or a REPL next to my code. It is near impossible to do that on a laptop if the line length is extended to 110 without a line wrap.
Point being, everyone has very different preferences and work practices. Team standards are going to be very different from team to team but standards do help reduce cognitive overhead on wondering if line lengths or other styles need to be different.
100% this. The teams that I have been a part of that have had a lasting impact on me allow for authenticity. Sure, sometimes you get a disparaging remark that can escalate. But, in my limited experience, that downside is so minuscule to the upside of having authenticity creating happiness in the workplace.
To add to this sentiment, tests also give teams confidence that is needed. It gives engineers confidence when developing new features because the test suite will break if you introduce a regression. It gives engineers confidence during deployment/CD.
While the tangible benefits of unit tests are very important, there are other intangible benefits that are equally important.
The single most important reason to test your code seems to be that it allows you to refactor your code while ensuring it still meets the original outside expectations.
The author’s main gripe seems to be about tightly coupled tests that make refactoring larger systems more difficult, and about prioritizing meeting arbitrary metrics (lines of codes covered) rather that thinking critically about the actual benefits.
This is in line with his emphasis on integration tests determined by the business. I think that same thought process can be applied to internal components of code as well, and you can empirically determine the quality of your approach (roughly) by evaluating how often your tests change. If nearly every change breaks a test, that probably means they’re low value/too tightly coupled.
Excessive mocking seems to be the biggest source of evil in that regard.
What confidence do unit tests add that other kinds of tests do not?
The confusion here between unit testing and automated testing in general kind of illustrates the author’s point: we’ve become so obsessively focused on one kind of testing that we aren’t thinking critically about its alternatives (of which there are many others besides “no tests”).
Tools that have worked in the past for me:
- Confluence for long lived documents
- JIRA for time boxed groupings of work.
- Slack for real time comm if anything arises.
- "Culture" and Process Living Document
I ran a team of about 25 in the past and followed the following agile principles to help with alignment:
- retrospectives
- "sprints" (preference on the 3-4 week range)
- Sprint Review
Alignment, while tricky, isn't all that hard so long as processes are evolving from retrospectives and you have a single source of truth for long form documentation.
Believe it or not, _you_ and you alone can fix this. DELEGATE! Delegate enough to get back SOME of that coding time. Block off 2 hours a day as "Free Time" or "Creative Space" a la Michael Scott from _The Office_. People will respect that.
At my prior place of employment in which I grew the team from 0 to 25 in 3 years, I eventually delegated all the stuff I did not like and empowered my team to own it. It sounds like you can do something very similar with the culture you have there.
An example: At first I loved phone screens and getting to know candidates. I refined and built that process from scratch. Once that process was up and running, it was no longer the best use of my time to be hammering the phones and scheduling screens. There was a better use of my time and someone else that REALLY enjoyed that aspect of team building stepped up. I was able to move myself to the end of the recruiting funnel which freed up 70-80% of my time allocated to that function.
The opportunity cost was simply too high for the company having me screening people.
You can certainly find a way to do that as well.
If you feel like chatting more on this, my email is in my profile. Good luck and don't burn out! Your work should be just as fulfilling as your team members work.
I completely agree with this. It's actually hard to delegate too much. Almost all managers I've ever known have delegated too little. I think they're afraid that by delegating important parts of their job they're diminishing their role in the company, but it's actually the opposite. Leadership is not necessarily a zero sum game: you can elevate yourself while also elevating those you work with.
What is soul crushing to you is not soul crushing to someone else. You can certainly find people who are motivated to meet new engineers and talk and spend part of their day doing that than going to a meeting of choice.
If you are leading a team of engineers, chances are you have some form of recurring check in to see how the individual is doing. In those times, it is the leaders responsibility to understand what motivates that individual and what they enjoy doing. This way, your delegation is impactful in an empowering way and not a “well thanks for unloading the stuff you don’t like”.
I prefer people to opt in to the processes that need to be handed off as that is how you get true ownership, evolution, and trust.
There's less to delegate if you're a team lead with IC direct reports. The situation starts becoming a lot more complex when your reports are themselves managers or team leads.
You can even delegate to people that don’t love doing it but will happily volunteer for their own sanity. For example, I hate interviews and phone screens but if someone asked for volunteers I’d jump on it because I hate being stuck with a bad hire much, much more.
You can also ask for volunteers for something you want to delegate and if none are forthcoming try out rotating it. Consistency might suffer but at least you’re not making one person shoulder something the entire team doesn’t want to do.
I self admittedly have trouble with delegation, and maybe you or someone else on here can help. The problem I have is a lot of my time is spent in meetings. I can certainly throw meeting invites to my reports, but I think to when I was a developer and how grateful I was when my manager shielded me from meetings so I could focus on work. It's not that I don't think there's useful information in those meetings for the individual contributors, its that I think there's also a lot of useless information that would largely be a waste of time.
I used to think I hated all meetings but what I actually hated was pointless meetings, especially ones that could be hammered out in less time asynchronously via email or chat. I learned about the distinction when I dealt with a manager with some unaddressed control issues. Of course that was just the tip of the iceberg but it was a standout symptom of a bigger issue.
It’s ok to try to unload bullshit but it’s also important to make your employees feel like you trust them. If you shield them too much and firewall everything they can end up feeling like they’re just workhorses that can be swapped out.
In my experience, meetings follow responsibility. Make somebody responsible for the thing that causes the meeting and you'll get mental and physical time back. Plus you'll give that individual a chance to truly own something end to end.
There are meetings and other tasks that managers must take care of. I like to make a list of those things with a brutally critical eye towards what I _must_ do and figure out how to delegate everything else. Oftentimes this doesn't save time in the short term (you have to teach and then follow up with your delegates), but it works quite well over time.
Delegating interviews isn't a unique thing. A team Lead or a senior dev can handle a good portion of it. It's also important that a candidate have a good fit personality-wise with the team he'll be working with, not just the manager.
Disagree with this, this is why the industry is filled with junior engineers doing ineffective algorithm whiteboard interviews. Hiring is too important to leave to engineers who don't want to do it. Generally they will do a bad job because it's just an annoying thing getting in the way of their work.
Hiring is broken because engineers think it's just another problem you can apply typical engineering solution. Same kind of thinking that causes the terrible customer service in Google products like random algorithm locking out accounts.
I did a fair chunk of interviews when I was just a dev. I loved it, and I took it very seriously in terms of vetting programming skill and practices. I also felt good offloading that burden from a good manager.
What were your success rates compared to other teams who depended more on the manager for hiring? How often did your company fire people for poor performance?
Sorry, didn't mean these to come off so pointed, just super curious is all, not trying a gotcha or anything.
If you just chuck a random dev at the interviews sure. If you handover gently and make sure they've internalized your interviewing process it's a different equation.
In enterprise, I've mostly seen hiring broken because there isn't a dev in the room, just fluffy non-technical management.
> Hiring is too important to leave to engineers who don't want to do it.
Who says they don't want to? I'm an engineer, and I love doing interviews. Plenty of engineers are interested in human aspects of the job too, and would be greatful for the experience.
> Hiring is too important to leave to engineers who don't want to do it.
I'm trying to come up with a ballpark estimate of portion of co-workers who seemed entirely unconcerned about who potential new co-workers might be, and while a precise figure is going to be beyond me, it's probably close to an order of magnitude smaller than people who care somewhere between a bit and quite a bit.
Filtering out the people who don't care much also doesn't seem like it'd be a difficult problem: ask for assistance rather than assigning it.
Passion doesn't equal competence. It doesn't matter if they're passionate about doing interviews, sometimes that even makes it worse because they think they are raising the "hiring bar" but instead doing a really bad job at interviewing.
The disinterested engineer doing an interview is less harmful than this type of passionate engineer interviewing.
The current broken system started with Google. They had a hiring problem, too many candidates to interview. So what did they do? Apply principles used for scaling computer systems. Treat each employee engineer as a generic interviewer who can give a generic algorithm question. Scale across all engineering teams to handle the candidate load. That's the Google way, apply algorithmic scaling to everything.
It works except when the fundamental problem is a human issue like hiring and customer service. It's bad system but they get so many candidates it doesn't matter. And the company is successful, success hides all failures.
So other engineers in much smaller companies get asked to interview their future teammates. Sounds great in theory. But passionate or not, they have no idea how to do it. So they just cargo cult the big tech companies. Completely clueless copying of a system that was created for a problem they don't have (massive number of candidates).
Only the manager and lead engineer should be involved. They need to take back control and leave the juniors out of it.
So is the problem interviewing or is the problem cargo culting?
You dont get magically good at hiring because you are the manager or lead engineer, just like anyone else you have to practice and build skills towards this.
Dumping it on any level of engineer (or person) without education and training on how to conduct interviews will not yield good results.
There's a difference between "we are scaling this wrong" and "nobody knows how to do this thing" and "only the top boss should do this thing."
Some sr eng are great at team leading through interpersonal skills on top of technical, some are so good technically they lead their teams anyway, and I dont want the second group interviewing almost anyone.
> the industry is filled with junior engineers doing ineffective algorithm whiteboard interviews
What industry? I've been a hiring manager for years and am not familiar with this happening.
> Hiring is too important to leave to engineers who don't want to do it. Generally they will do a bad job because it's just an annoying thing getting in the way of their work.
So ask them. If they don't want to do it, don't force them. Most DO want to do it, because they get to pick who they get to work with, and do a fantastic job contrary to what you're saying.
Random algorithms locking Google accounts is nothing at all like hiring and I am failing to see the parallel you're trying to illustrate.
Absolutely this. You will want the feedback from the existing team anyway right? Why not have them form their opinion first, and only talk to the candidates that pass their screening?
Somehow, I feel like this is starting to sound like managers shouldn't do any work.
Managers aren't supposed to be coding as their primary responsibility.
I mean if you can find someone willing to do managerial responsibilities, then go for it. Just make sure you're not the one taking advantage of them and reward them for it.
A leader's job should be to effectively delegate themselves out of a job. If you think delegating effectively isn't "work" then I don't know what to tell you.
Leaders are not effective if all they do is throw work over the wall expecting other people to do it. That's the quickest way to isolate yourself and is why managers often don't know what's going on in times of problems. It's also the quickest way to get employees to hate you because they view you as useless.
And this is especially true when its a task managers should be responsible for, like hiring people.
If the point is to make them have no job, then why are they even needed in the first place?
Work themselves out of a job, not necessarily delegate. The former could mean solving a problem once and for all, or putting process in place, or eliminating a task. The latter means having someone else do it.
Most times you are correct. In this scenario, however, it seems like he started as an individual contributor and transitioned to management. When that happens, in my experience, companies want to continue to leverage the system knowledge from the individual in some form of producing technical assets.
Place some trust in your reports; they're going to be working with the candidates if they are hired, they might as well interview them, too. And they could probably use the practice.
In fact, the worst hires I've had to work with were hired by my manager without involving the team at all.
I think it’s also worth mentioning that if you’re going to involve the team make sure you’re prepared to actually objectively assess and act on their feedback. Not necessarily saying everyone should have veto powers but we can tell when you’re blindly excited for a candidate and are disregarding anything negative that contradicts that. Don’t waste your people’s time if you’re going to ignore what they say and do whatever you wanted to do anyway.
All the hiring processes I've been involved in are primarily driven by individual contributors. The manager probably makes the ultimate hiring decision, but engineers are better suited to do the technical portions of the interview anyway.
Invite team members to the screenings, get them to ask questions and understand people. After a while, the member could do it all on their own, and maybe even train someone else. Try different people, look for talents inside team :)
At one point, you can give away resume reading too. And talking with HRs will get easier (more repetitive/automated) after a while; try to engineer a way for that.
There are definitely portions that can be delegated. I was doing interviews in the first month of my first job out of college. The trick is to do pairs: one person who's new to it, and one person who's had plenty of practice.
If I ever assign myself dev tasks they never get done because something else will always come up that's higher priority. I only ever take small tasks when I'm having a quiet week. Usually I'm preempted by meetings. This is the way of things.
I know we are talking about this in the digital realm, but this also exists in the property realm too. Imminent Domain is used be governments to acquire land, generally below its actual valution, for building of infrastructure.
I wonder if this concept will ever make it to the digital world.
I am against emi ent domain but at least it is justified by the fact that there are no alternatives. A road between two points must pass through some land, but if a domain name for your website isn't available don't be a bully and buy another one. Also you have to compensate with eminent domain, you can't just take. Not in decent societies anyway.
What we have here is maximum statism. A bunch of french bureaucrats had some stupid idea on how to spend stolen taxpayers money to "improve" society, and they used their position to steal a domain name from a guy who was minding his own business.
In this case bureaucrats should be condemned as if they were thief.
> In this case bureaucrats should be condemned as if they were thief.
I don't think the public gets to go scott free in this. France is a democracy. If the French government does something, all French people are responsible for it. That's what the world says about us, why not France?
Pretty sure France can't "imminent domain" property located in foreign lands -- like, for instance, they wanted 1600 Pennsylvania Ave as their new US tourism office.
It does not have complete feature parity. One of the things missing, that is important for me and the team I am on, is the ability to share screens and allow for remote control in that session. That is a Mac App only right now, at least the last time I checked.
Now that screenhero is no more, screen sharing is literally the only reason one of my teams use slack. We use hipchat (not by choice) for the rest of our communication.
It’s a little crazy to me how Twitter profiles with Apes are viewed as “influencers” and “pioneers” and get treated as such. Not my cup of tea per se, but there is tangible value for some people there.