> 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.
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...
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!
> 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.