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

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.

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.

Over 8 years, at 4 different companies of various sizes...every place I've worked at had some grating issue(s), I've just learned which ones I'm willing to deal with.

A few for myself:

- I've come to accept that impactful teams often deal with ~50% interrupt-driven activities due to top-down mandates or fire-fighting. Real users, real value, real pain.

- Everyone pulls their own weight, but the annual raise isn't as high. Being the big fish in a small pond has diminishing returns - I might get a fat raise every year but the stress from being forever resigned to all the stuff nobody else can or wants to do is unsustainable.

- Team does not ask algorithmic puzzles (i.e. leetcode, epi) questions. I just don't have the energy to practice studying for them anymore, and hate asking them to people even more. However, I will say that doing so at one point in my career literally doubled my income, nevermind that the test taking skills I developed had no effect on my job performance. I probably left a lot of money on the table by not having tons of offers at once.

Comments URL: https://news.ycombinator.com/item?id=27210743

Points: 4

# Comments: 1

Of course if there is no other option, we would pay the substantial amount of money to get the photos back - but if we can pay significantly less to have someone reverse the encryption key, that would be preferred.

Does anyone know of a service that reliably does this in the bay area or in the states?

Thank you...

Comments URL: https://news.ycombinator.com/item?id=27124552

Points: 3

# Comments: 1

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.

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

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?"

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.

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.

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.

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.

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.

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

Comments URL: https://news.ycombinator.com/item?id=20403132

Points: 1

# Comments: 0

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.

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