> 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 use "blocking" code you must be running in a Java thread. You cannot "block" the main javascript thread. Generally all of our code runs on a Java thread. For JS events (which always occur on the main JS thread, I just wrap in new Thread(()->{...}).start();
> 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 would say, respond that you don't know the answer from the top of your head (assuming that's the case), and politely refer them to read the documentation (or experiment).
If the documentation doesn't exist, consider creating it.
If they ask same questions again and again, suggest them to take better notes.
I think complaining about it is counter-productive. Force them to do the legwork, explain that it is primarily their task to do research on a topic.
> 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.