ThorinJacobs

Forgive me, but these don't sound like instances of arrogance. You've pointed out flaws in execution or feature, and I would do the same, but that's not arrogance. That's just doing your job as a developer.

Maybe you achieved these in an arrogant way? I'm not going to deny that you can get things done being arrogant. But I don't think it's necessary to getting things done right.

Could you provide some examples of times when being arrogant improved the quality of the product you delivered?

I've certainly run into arrogant engineers in the past. I spent the 2-3 weeks after the worst of them left cleaning up his bug-ridden, brittle code. If he had worked more collaboratively, it wouldn't have had to be that way.

I've worked on systems that had the CI system set up to only fail style or inspection when the overall issue count was larger than the previous one. Over time, your issue count will become asymptotic toward zero. There is a gap in that if you add new code that has issues at the same time that you refactor and remove issues, you won't be alerted. So...don't do that!

Tests have also been very helpful. So say I'm in a situation where the legacy code is not style-compliant, let's forget the style-oriented analysis and double down on adding tests. Once you have good test coverage, start to clean up the styling and start to think about static code analysis as part of the build.

I don't read the parent comment as claiming that the people in power are not hard-working or talented, nor that they don't care. Rather, I read it as asserting that many white men have had the privilege of not having to deal with discrimination and harassment, and that it doesn't come to mind as easily as it does for underrepresented individuals.

Just like a developer is going to spot defects in applications more than a non-technical user because they are exposed to defects more often and understand where things will fail, people who have lived discrimination will be more likely to see it where it happens, and understand where to look to find it.

I'm always surprised that this isn't more widely known. Why else would stores have rewards programs?

Use of abbreviations is one of the greatest contributors to cognitive complexity I've seen in code. There's been plenty of times that I've renamed the variables in a method and all of a sudden what was completely inscrutable is really very simple.

Acronyms are a particularly nasty subset of abbreviations because they're accepted in discussion of business needs and even in tutorials and documentation.

> Everything is violence if you think hard enough.

Yes, very much this. "Violent" crimes clearly have a more evident immediate danger, but all theft is violence (though the scope might not be immediately evident).

This applies especially so toward individuals who are already low-income. Steal a low-income person's wages, and they fall deeper into the pit of poverty. They can't make their rent payment, their electric bill, they overdraw their account maybe. They haven't just had an hour or two stolen from them.

I am not, nor have I been a team lead, but will pitch in with a couple ideas.

It sounds to me like the other managers don't believe that the metrics you are using will result in higher productivity faster. This could be because they just don't understand or haven't fully internalized the benefits of passion etc., but I suspect it's more likely that they're feeling the pressure to higher someone, anyone. Assuming you have enough autonomy on your team to make a hire based only on the merits you list above, have you been able to demonstrate to your higher-ups that your method is more effective? If the higher-ups understand what's better about your approach and that other teams aren't following it, they may be able to start changing the culture or putting pressure to change interviews.

I'd also recommend re-examining the "must be better than the last hired engineer" point. Different engineers excel in different areas and I suspect you'll run into problems like "well they're much better at algorithms than the last hire but they didn't ask the requirements questions I'd like", etc. To me it seems like a weak link that your peers may focus on to the detriment of your other goals.

Again, not a team lead, just suppositions and suggestions based on the engineer side. Mostly just sounds like a company culture issue, gotta make the superiors understand why haste makes waste.

That's a totally reasonable sentiment and I can totally see how I didn't clearly articulate my feelings on the matter.

Of course we do want new tooling - ES6 and Angular in particular have worked well for me. Where I have some trouble is the tendency of some organizations to adopt these frameworks without considering whether the framework is actually solving a problem the have or expect to have in the near future. YAGNI is very tricky to get right.

As others have said, going "T-shaped" where you master a small number of languages and learn the basics on a much larger number is probably the way to go.

For language recommendations, it depends a little on what you're ready for, what cognitive load you can take on. If you need to pace yourself, focus on one or two paradigm differences at a time.

Want to "dip your toes" without giving yourself a ton of cognitive load? Try doing some work in C# - being familiar with Java, you should be pretty comfortable with its idioms, and can ease yourself into functional thinking if you're not comfortable yet. JavaScript and Python are good choices if you need practice with dynamically typed, interpreted languages. JavaScript is pretty much necessary at this point. If you're dealing with Big Data(TM) you may want to look into a functional language. Haskell is probably a good choice there, but F# may be worth experimenting with as well.

As for evaluating the languages, Project Euler is good, but I've personally found Advent Of Code more helpful for learning. Advent gives you sample input/output that is perfect for setting up unit tests, and the problems are less math intensive so you can really focus on the new language and what idiomatic code and architecture looks like.

Good luck!

Tired of JavaScript? Not particularly. Tired of the #hype around JavaScript and more specifically the constant frameworks of the week? Absolutely.

I don't think this is a problem unique to JavaScript, however. We see the same sort of thing around technologies. Right now it's ML and Blockchain, earlier it was Cloud and IOT. The industry in general appears to be mostly built on inventing problems that can be solved by the tech, framework, etc. rather than leveraging technology to solve an existing problem.

This may be part of why you're having a hard time finding the problems JavaScript may solve for you. Personally, I find it much easier to follow the "Just In Time Learning" model https://blog.codinghorror.com/keeping-up-and-just-in-time-le.... Find out what parts you need in order to solve your problems, learn how they work, and leave the rest until you need it.

This may be internally consistent, but what of applicants following up on their applications? A sizable portion of the workflow believes - and is advised by job search coaches - that the correct response to being ghosted is to follow up on the application. Do you not waste more time fielding and diverting followup calls than simply sending (at minimum) a quick form email to remove all doubt?

In this case, a JavaScript front-end that had no unit tests previously. I also wasn't able to get NPM through the firewall, so I used Jasmine standalone and kept its files and copies of our third-party framework files in a "Frameworks" folder within a separate "Test" folder

The pushback I received was that keeping the framework code in Source Control would result in it being caught in the JS build/minification script, as well as my spec files. The individual that pushed back was also concerned about JS exceptions since we were up against a release, which speaks to a need for training about how unit test files work. Ultimately I .gitignored the framework folder but wouldn't budge on leaving the test files in, since .gitignoring unit tests defeats the purpose. Then I learned that the build script wouldn't grab those files anyway. :)

This is really great advice. You're right - it's really easy to make assumptions about the code and it's definitely caught me at least once!

So far I've been trying to keep my changes in service of a specific feature, and keep as light-touch on existing code as possible whole still making improvements. Wrapper classes have helped with this a lot.

Thanks! Yes, so far my previous teams have been very diligent - almost too much - about testing and refactoring, and I'm trying to be very cautious about not offending.

This sounds like very sound advice - slow and steady wins the race I suppose

I've had some success building technical debt into my estimates. While I'm working on a new feature or a bug, I'll tidy up in the area around it - the tidying up is just part of the work necessary to complete the task.

The really cool thing is that eventually you're able to deliver large, complex tasks in very brief times and then spring on the PM/management that you're able to do this _because_ you've been refactoring. That's made a believer out of at least one of my PMs.

Obviously this doesn't work in all circumstances - it's not always feasible to get the really systemic, contagious debt cleaned up as part of feature work, and if the PM catches on then it makes this tactic difficult to continue.

The bigger obstacle I've had, though, is other developers who haven't fully bought into a culture of continuous improvement. Fear of breakages causes refactor paralysis, which makes it easier to break things when working on them, which increases fear, and so forth. I'm not really sure the best way to deal with that aside from adding a bunch of unit tests (which I still sometimes get pushback on)