d0paware

I'm just shocked at how resistant people are to new technologies and ideas that could make things so much easier

I see how so many things we take as standard in the industry are incredibly slow, overcomplicated and inefficient, but when I try to introduce new ideas or patterns at work they're unfamiliar and therefore "too complex"

Almost everywhere I've worked there is always resistance to change - but not always because people are too lazy to learn new things. There's an inherent cost for a team to adopt something new - there's no free lunch. Especially when it comes to new technologies, if your team doesn't have the chops to dig into the source when things go wrong, you're probably not going to have a good time even if they do adopt it. And new technologies can be incredibly complex - can your team manage the complexity? Who will support and own the builds, the deployment process, troubleshooting, etc? People who cry at the first sign of trouble will continue to do so.

You have to justify it to the team, the manager, or the business. Oftentimes if you ask for permission to add something new, you'll probably never get it. If you go ahead and prove empirically to everyone that it works, and it works better than the old stuff, that's a great way to start adoption.

Of course, if you still can't get adoption without legitimate reasons for pushback, I'd say the team culture is the real problem. People on the team think learning new things is more work, and why work more for no pay increase - especially for a job they don't really care that much about anyway?

If you work on one of these teams, you might as well just power through objections and just do whatever you want. What do you have to lose? Even if you get fired, big whoop - you weren't gonna last long there anyway. Of course, this is all predicated on the fact that you are competent and not just automatically dismissing real concerns of teammates - if you go full cowboy and actually break everything, you deserve the consequences.

I've worked at awful places like that too, but I've been able to find the top 5% of competent folks and work with them to make life more tolerable. It's hard to find a place with curious folks that dig super deep into stuff. You have to really grill the interviewers or ask to see their codebase, or know someone who already works there. I only interview with places where previous coworkers I trust already work on the team now to avoid this problem.

The first step is to figure out what's actually causing you to burn out, which sounds easy but is usually a lot trickier because you need to be far away enough from it to see things objectively.

I recommend starting a journal and writing down all the things you think are causing the burn out, especially when you are feeling overwhelmed.

Some areas to think about:

- Your expectations: where do they come from?

- Habits and routines: are they healthy? According to you or others?

After about a few weeks or a month of doing this, I recommend going to a park or somewhere quiet you don't usually go (or maybe, never have been) and reading over what you've written. The point of this is to get you out of your default setting where you might fall into a positive feedback loop where you can't imagine other possibilities or where you automatically shutdown any kind of solution proposal.

Start by prioritizing one issue to work on, and start recording your progress on that thing and see where it takes you. When that gets better, take on the next thing, etc. Small, incremental improvements. This applies to anything you think is a problem: sleep, exercise, job satisfaction, etc.

Something to realize here is that you want to make as much progress on things you can control at the time, and you won't always be able to effectively tackle certain problems with your current self or tools.

It's sort of like those games where you get stuck in an area because you haven't done the pre-requisites nobody told you about yet. It's OK to give up on something you're making no progress on (as long as you tried everything and kept track of it) and do something else you can make progress on.

1) Vert.x (https://github.com/eclipse-vertx/vert.x) - Reactive framework (think Node.js on steroids) built on top of Netty with awesome HTTP and JDBC support. I use this to build anything that's performance sensitive or cost to serve is important.

2) Spring IoC / spring-context / spring-beans (https://docs.spring.io/spring-framework/docs/current/referen...): Spring is still pretty awesome for dependency injection. You only have to import what you need. Also a fan of Spring Boot but you need to be pretty opinionated about disabling auto-configuration or just pulling in what you need. Injecting whatever Spring library you need becomes pretty straightforward after that.

If you're going to adopt any of these technologies though, your team needs to be able to look under the covers when things go wrong or you need to do something sufficiently custom.

Sorry - studying for the puzzles / leetcoding to line up a ton of offers. Leaving money on the table is in reference to not studying now.

Thank you - I will check this out.

This is a very underrated observation. I've seen teams where all code reviews pass through one or two individuals.

The "core developers" become a bottleneck to all changes, even if they offer the best feedback available. The team eventually leans on them as a crutch to catch all problems, progress grinds to a halt as everyone is waiting for their code to be reviewed by X, the core developers don't get any real work done, and the rest of the team never levels up because they don't learn lessons that sometimes are only learned the hard way in production.

Good leaders know how to "let go", delegate, and recognize when they're becoming part of the problem.

On the contrary, I think language expertise is underrated and I want new hires to start doing things immediately with minimal support. Also, people with mastery in one language often prioritize figuring out how to do the same things in other languages if they switch.

Anyone can start coding in a different language, but it just takes that much more time in implementation and code reviews when they lack knowledge of:

- Standard libraries

- Builds

- Debugging

- Etiquette

- Performance gotchas

BUT - if you're going to ask for language expertise you better evaluate it in the interview, because years of experience is a garbage metric.

Put someone in front of their IDE and watch them build and debug exercises. i.e. how do people troubleshoot issues with dependencies, tracing, optimizations, etc. I wish more places would have -relevant- interview sessions about "OK, how much do you know about the tools you use?" Obviously if you're a applying for a position where perf expertise isn't important, it's not fair to ask you about GC internals.

Some people really struggle when it comes to tools or languages outside of their expertise. While I personally don't love working with these types, that doesn't mean they don't have value.

You can be a die-hard JVM guru who refuses to work full-time in any other non-Java language because you're productive as hell and don't want to spend months re-learning how to do everything again. Honestly, I'd much rather work with a team of these types than a team of people owning 5 microservices written in 7 different languages...

(P.S. I love Java for all the hate it gets here.)

1) You can anticipate complexity - the what, where, when and why of how it shows up. You are not afraid of it, but...

2) You manage your time well - yours and others'. Figure out when complexity needs to be handled. Respect other peoples' time, they also have important things to do that don't involve you. While you could spend 1 month to figure out the answer to this gnarly bug in open source software after running strace and tcpdump and poring over the linux kernel source code...ask yourself - is this the best use of my time? The answer might still be yes. Just don't forget to look up every once in a while.

3) You prove your skill at 1) and 2) to yourself and others by empirically testing your decisions and evaluating the results.

4) You realize there are trade-offs to every decision you make. This sounds trite until you recognize that things that seem like no-brainers to you aren't, to others. This also applies to how you choose your workplace. Every place I have ever worked at has one really fucking annoying issue, but I have seen enough of these that I can rank them in preference.

5) You are aware of how others perceive you. Peer feedback on your performance should never be a surprise to you. If people were scheming against you, you probably should have known.

I guess after you feel comfortable with these things, you kind of stop caring about the answer to "am I experienced enough?"

What's the recommended way to drop into blocking code? For example, if you already have a worker thread pool executing some blocking code.

I am guessing it will automatically look for static occurrences of park(), wait(), etc anything that goes into a blocked state and yields to the next handler on the event queue?

Even with the coroutine support, it doesn't seem smart enough to make something like "while (true) { ... }" auto-yield to other functions or handlers on the event queue. To be fair, it's not like javascript does this for you either.

To start out with – sometimes the people asking you questions don’t respect your time, and that sucks. I’m assuming here throughout that that’s not what happening.

I'm curious, how do others handle interactions with people who don't respect your time? I'm talking about coworkers who do not improve in their question asking ability after you've gone through the processes the article describes multiple times in good faith. People who Slack or email several people in parallel, waiting for the first reply to come back.

I've found that being honest with problematic coworkers - i.e. asking them face to face to invest more effort - is a risky thing to do. Even as an authority figure on the team, it's easy to develop a reputation for being an asshole, even if you're as polite as possible. Instead, I save the feedback for my manager with concrete examples, and have them deliver the bad news.

A lot of managers need to receive overwhelming feedback that the offender is doing this, so you may need to prompt them to ask other members of the team to solicit feedback. Some people are too nice to bring it up. Even then, it's notoriously hard to correct behavior in these individuals and even harder to get them off your team.

So when everything else has failed, I ignore messages from them for maybe 2-3 days, and then reply back with "sorry, did you still need help?" and continue stonewalling them until they give up. It's most effective when you can get everyone on the team to participate so that the person is forced to pull their own weight.

I recommend time-boxing how much time candidates will have to spend on your process. People coming from an alternate career path still have to pay their bills through their current job and tend to the same responsibilities as anyone else. Asking them to do days of unpaid homework (https://news.ycombinator.com/item?id=16874015) may not be a luxury they can afford.

For the take-home portion of your assessment, consider paying the candidates for their time at an entry-level annualized salary. Many companies would balk at this idea because it is more expensive, but it demonstrates respect for the candidate.

Looking at the website, I don't see many details about what the assessment actually includes. I think it would help to be forthright about the structure of the assessment. Does Hatchways or the employer determine what the assignment is? How does one create a rubric for scoring a submission, and how is quality assurance conducted on the effectiveness of these rubrics?

I think it is only fair to tell candidates what area of expertise they are going to be tested on a week ahead of time, so they can prepare as they see fit. As for this bit: "ability to follow a spec, code quality and how quickly the task is completed" - it would make sense that different companies would place different weights on each of these factors, given that some of these parameters can often be at odds with each other.

Also - a particularly tricky area: how do you give feedback to candidates? Do you help them succeed? Is it enough that Hatchways gives the feedback, and not the employer to avoid lawsuits? Having done some take-homes in the past that were rejected, I received absolutely no feedback on what could have been done better or what was missing. Candidates who continually to struggle and don't pass any of the interviews aren't necessarily morons or inept - they just need someone to point them in the right direction.

The problem with being self taught, at least in my experience, is that you end up being very strong in whatever areas it is that interests you, and whatever areas of CS are relevant to the projects you're working on day-to-day.

I think this is the case even if you receive a formal CS education. I picked the most difficult or interesting classes and got As in them, and barely passed everything else in order to graduate in 4 years. Many students avoided the hard professors to protect their GPA, so it was really easy to register for them since 25% of students might drop the class.

Probably the most important thing a formal CS education does is expose you to CS fundamentals, but in my experience you end up having to be self-taught in a university setting anyway. Most of the professors I had were more interested in research than in lecturing - many lectures were completely incomprehensible. And even with amazing lecturers, I would still have to spend hundreds of hours reading and practicing on my own.

One of those classes I barely passed was algorithms, since my other workload was too great. I eventually had to self-study this subject years later to pass the tech interview torture chamber.

College was mostly an exercise in self-learning or learning how to learn for me - something I am still reaping the benefits of today.

Yeah Peltor earmuffs are about the only thing that have worked for me. And you're right, a salary or fine is never going to work out practically - just wishful thinking on my part :)

Open office plans are wonderful for the micromanager. Everyone's screen is for all to see - and the moment someone happens not to be looking at an IDE, it's an opportunity to ding someone on their performance review.

While I personally am hyper-focused at work (perhaps too much to the point of tunnel vision), I know peers who have received negative comments despite delivering stellar work - all because they look at HN or doing online shopping from time to time.

I'm not against collaboration, and maybe open offices can be good if they are treated like public libraries. People can go and discuss things in a room somewhere where they won't bother everyone else. The problem is finding someone (HR, management, etc) who will enforce this policy and actually provide consequences to violating the quiet zone rule.

How about a 0.5% salary pay cut every time you randomly interrupt someone's flow via tangent conversation or unwarranted shoulder tap?

Open office plans originally exist purely to save on costs. If a company doesn't do it to save on costs, is it appropriate to blame cargo culting in the name of "synergy and collaboration"?

If I really need to concentrate and think about something, I need complete silence. No music (even if it is instrumental or repetitive), no headphones, no coworkers taking phone calls, arguing over their code review, or discussing how everyone died in last night's TV episode.

My brain for some reason decides it has to eavesdrop on every single conversation within audible range, and trying to re-align myself to the task at hand becomes excruciating since every 5th word I hear is like a call to `Thread.interrupt()`. If you put me next to a jet turbine or some other white noise, I'd do much better. It might even solve my problem permanently by making me deaf.

If I already know what I need to do and it's just a matter of hitting the keys on my keyboard, I can tolerate the noise.

I commonly joke to my peers that perhaps management is doing us a favor by slowing us down day-to-day so we don't automate our jobs away too quickly. We should all be thankful!

Previous HN discussion: The open-plan office is a terrible, horrible, no good idea - https://news.ycombinator.com/item?id=17513843

In any situation that I would use "please" or "could you", I substitute in "what do you think of / about".

For example:

"What do you think about changing these variable definitions so they're easier to read"?

This gives them a chance to reply and even disagree with what you're saying, because maybe your premise is actually misguided.

I think probably one of the most valuable things you can do with your junior developers is to set expectations around how to ask good questions. Your goal is to help juniors strike the right balance between spending time figuring something out on their own versus spending too much time and going way off track. You also don't want your juniors to ask too many questions that they should have first spent some time investigating on their own.

There's a good link on this: How to Ask Good Questions (https://news.ycombinator.com/item?id=13293301)

Other than that, I think having a junior shadow you while you debug a bug or help them debug one of theirs while explaining each step you are doing is also very helpful.

Something else that's pretty good is to give juniors a shining example of a high quality SPIKE task on a new technology or design consideration. You want them to learn by example.

And here are some other links that I've found personally helpful: https://softwareengineering.stackexchange.com/questions/1383...

For you:

Ask HN: How to manage developers who "aren't very good" (because let's be honest, we've all had this sentiment before whether or not the developers were actually bad or not) https://news.ycombinator.com/item?id=9008845

For your juniors, to give them something to aspire to:

On Being a Mature Engineer https://www.kitchensoap.com/2012/10/25/on-being-a-senior-eng...

Ask HN: How to Be a Good Technical Lead? https://news.ycombinator.com/item?id=10395046

But is it less expensive than other methods of interviewing?

I'm going to assume you are including the costs of firing people as part of "interviewing" after they have been hired and found to be a bad fit.

I'll take a stab at this. 160k annualized per hour is about 77 dollars an hour, if we're assuming 260 work days a year and 8 hours of work a day.

$77 * 4 hours of a day = $308 additional cost per interview. I'm going to assume you're already doing some panel interviews with at least 2 people, so I won't include their cost in there. And there's potential savings if we only have 3 people interviewing for the 4 hours instead of 4 or more.

Let's say I am trying to hire for 20 positions, and I am willing to interview n=15 times per position.

20 hires * (15 interviews * $308 per interview) = $92400 additional cost, whether I get 0 or 16 successful hires out of this process.

If we think about the cost of onboarding someone with 3 other employees who are getting paid about the same over a period of 3 months:

308 * 3 employees helping with onboarding * 65 work days * 8 hours * 10% of time spent onboarding = $48048 cost of onboarding 1 employee

Let's define a bad hire as someone who contributed no value and we'll treat the salary we paid them up until the point we fired them as a sunk cost. It takes maybe 4 months (260 * 4/12 = ~87 work days) to figure out that someone should be fired if it's not super obvious?

Let's say we would have normally only hired half of our target candidates (10 out 20). I'll also be conservative and say the new process reduces the number of bad hires by 10%. So assuming 1/10 of our actual hires was bad:

~87 work days * $308 per day + $48048 cost of onboarding 1 employee + ~$5000 for health benefits = $79844 cost of firing 1 person, not including the cost of other employee benefits, the effect on morale, etc.

So here you're adding a cost of about $12556 dollars. I think the cost of firing someone is actually a lot higher than what I have calculated here, though I don't know what the actual figures are for that.

But I feel that if candidates at least enjoy the process more (which based on this thread, it seems like a lot of people here would), then isn't that a drop in the bucket in the company's bottom line for something pretty valuable?

There's obviously a lot of other intangibles at play here and we can model this all sorts of ways. Let me know if I've made some egregious error.

Interesting, have you had success with this approach? I might imagine there could be some stigma associated with this since why waste time if there's no guarantee of full time employment?

In California, it is at will employment anyway but I get the feeling that contractors are easier to fire than employees. Correct me if I am wrong.

On the other hand, candidates who are actually good will do very well and get through without any problems. I feel like it would take at least 2 to 3 weeks to find red flags, then at least 3 months to determine if someone is a superstar, and at least 6 months for everyone else to shine through.

Do any of the solutions I've personally suggested or mentioned here in this thread seem reasonable to you though? I was hoping we could at least talk about trade offs or pitfalls of various things people have suggested.

I feel like maybe I screwed up here with the thread since it got flagged early on for having Ask HN in it, and people responded with a knee-jerk reaction going straight to the comments section. Not sure if it's possible to get a mod to rename this and remove the Ask HN, I originally tried to paste in my content directly into the self-post textbox but 9k chars exceeded 2k chars.

- Not doing any coding opens you up for people who can talk, but not code.

I think candidates should definitely code at least fizz buzz or something as a sanity check. It probably shouldn't take more than 10 minutes.

- Problems to take home are an artificial setting

How do you feel about potential solutions I have mentioned in the post, e.g. exposing the candidate to a project during the on-site for 3 or 4 hours?

I'm also not a huge fan of take home projects unless they can for sure be time-boxed to be less than 4 hours, and it would be ideal if you actually got paid for the 4 hours of time.

- On the other hand, if you're using real code from your project, you're just asking for unpaid work. And paying every candidate is a significant expense.

Paying every candidate is an expense, but is it less expensive than hiring the wrong candidate and then needing to fire them? It seems like other comments here have already pointed out that they pay something like 160k annualized salary hourly rate, which seems pretty reasonable.

Really good points here, especially #3. In the past, we've looked at all the candidates we hired who turned out to be high performers (gets stuff done in a timely manner, writes tests, pushes back against unreasonable deadlines, doesn't require too much hand-holding) and looked at how they scored on the rubrics / and who was interviewing them. We have even been able to tell whose hires have been relatively not so great, but this takes earliest 4 months and usually up to 6 or 8 months to figure out.

I tried to paste all the content in but it exceeds 2000 characters, I thought providing my experience might help generate more discussion.

Does it make more sense to paste the link into the body of the text and just ask the question?

I can move this to pastebin? Is that better?

I used to think that this was a good way to cope with unhappiness that I experienced. I would tell myself, "At least I'm not starving to death" or, "At least I don't feel like killing myself this morning." I would feel better at first, but it didn't change the fact that I would still get the same negative feelings again. It became frustrating that this tactic lost its effectiveness over time.

While on one hand it trivializes what it actually means to go through starvation, or having suicidal thoughts, or what it's like to actually be a slave, I think it also trivializes your own feelings as well.

Like the article points out, this mentality suppresses your feelings. "Oh, I'm not allowed to feel this way. Look at all the wealth and happiness I am surrounded with and non-extreme situations I don't have to face!"

Admitting my feelings and writing them down in my journal in the heat of the moment, no matter how pathetic they made me seem, gave me a chance to reflect on what I had written. It gave me a snapshot to come back to later and say "Is this really what I am like? Have I exaggerated or downplayed my emotions?"

And from there, I was able to come to two types of conclusions:

1) Accept that sometimes for a given situation I would feel blue no matter what. Something I realized after 8 years of heartbreak, things not working out, or rejection in dating is that while I got better at being functional, the pain itself never dulled. And what a relief! I kept expecting that it would somehow hurt less after all these years, but that's just not how it turned out. And I feel so much better now with that in mind.

2) I can decide to act on the problem. I can act and succeed, or act and fail. And after enough failures, sometimes it's OK to give up for the time being and work on other types of dissatisfaction.

I think the article did a great job of succinctly describing a process I have gone through myself for several years. I highly recommend it.