I'd rather hire an 'interesting' developer who wants to build and consistently upgrade a product with the latest tech then someone who believes it too difficult. Who says your stack cant change over time, ever heard of agile development?
Choose boring employees
31–40 of 44 posts
Re: Choose boring employees
#32Tech choices matter. The industry evolves and all of this experimentation in languages, frameworks, tooling, and libraries has led to real productivity gains. 10X developers may be rare...but I don't think it's so rare to see 10X productivity gains when it comes to tech stacks. For example, a company who runs their own servers manually can see dramatic improvements in productivity and agility if they move to a newer…
Tech choices do matter, but I think the point of the post is that some developers chase tech choices for the wrong reasons. I don't think of a boring developer as someone who wouldn't look at transitioning from locally hosted servers to AWS. I think of them as the kind of developers who would have considered the move in terms of a cost/benefit analysis rather than doing it just because the cloud was the new hotness. The non-boring developers the post is talking about are the ones who would have immediately moved to AWS when it came out, just because it was new, and then kept moving to whatever the latest PaaS flavor of the month was every few months just because it was newer.
I think those non-boring developers have good intentions, and certainly think of it in terms of staying on top of the industry, but I'm not sure they weigh all the factors in their choices. In particular, I think they tend to overestimate the benefit of switching technology while underestimating the cost to switch and the unknowns that come with a new technology. More than once I have heard a developer argue for doing a fair amount of work to switch to a new technology to gain what is in the end a relatively minor improvement.
In my experience, it's certainly possible that a new tech stack could dramatically increase productivity, but even more often it seems like the result in the long run is a heavy lift to embrace the new technology, followed by the discovery of unknown issues, followed by being underwhelmed by the improvement in the end product. I think it's worthwhile exploring new technologies as they come out, but on a strictly evaluation basis and with the understanding that switching to them should be a the result of a measured analysis rather than doing so just because they are new and exciting.
Re: Choose boring employees
#33Reading the title I thought the article was going to talk about how not to hire for culture fit nonsense like playing foosball or ability to down a keg but instead it talks about hiring people who don't care enough to keep up with tech advancements.
Re: Choose boring employees
#34I believe in hiring the very best employees that fit the culture of your company. If your culture is a boring one, then hire the best employees which would fit well into a boring culture. If your company culture is vibrant and outgoing, then hire the very best employees that will thrive in a vibrant, outgoing culture.
Re: Choose boring employees
#35Earlier quoted context omitted.
I built an private side project app that was in use at of the major brokers. I built it in react redux, because I thought it would raise "my" value. I've had to rebuild that shit more times than I care to admit. Imho for a small dev shop picking react is a stupid choice. For a small dev shop picking node in the backend is IMHO also a stupid choice. I could go on with the list, but I'm going to stop knowing that I wil…
If react/njs is a mistake for web side projects, what would be a good alternative?
It's not a mistake. It's a great framework. Most of the complaints I hear about React come from folks who dislike JavaScript. JS is a great language for a side project. Make sure you learn fundamentals of JS. If you want an easy way to build a static web application with React, use Next.js. It's dead simple, no config, the folder structure acts as your router. https://github.com/zeit/next.js/
Re: Choose boring employees
#36The flip side of this is that you have "boring" companies and employees who are reluctant to change even if it would make a demonstrable improvement. Doing things because you've always done them this way is just as much of a trap, and I'd suspect far more common outside of the startup realm.
Re: Choose boring employees
#37Earlier quoted context omitted.
I think you should hire energized, motivated, continually educated employees that stay at the top of their game...not boring ones. I think the point of the article, which was rather subtle actually, is that "top of their game" is best defined in more general terms than simply "skilled in the top random webby crap from from the last 18 months". I've been able to rewrite front-end code in a different framework with les…
The app I'm mentioning was pre-Webpack days, like 4-5 years ago. Just using KnockoutJS...which has no dependencies. It made me realize that tools can dramatically impact my output as a developer. Dependencies can sometimes be a pain in the ass to manage...but they are a huge net positive for productivity. When the choice is between downloading a battle-tested autocomplete package written and maintained by someone lik…
Right -- moral of the story being, one needs to evaluate any given framework import choice on its intrinsic attributes, pro and con. Not simply on how new and shiny it is.
And potential collaborators and colleagues, likewise. Just give me people who are solid in the better practices of whatever language they use (even if it's Java or vanilla C) -- and reasonably aware of the current landscape (even if they chose not to, or heaven forbid, the quotidian needs of the real, money-earning products they work on don't exactly make it feasible to adopt the latest and greatest tools or platforms) -- over the type of folks who instinctively cargo-cult nearly everything that's been trending in the last 18-24 months -- any day, please.
AngularJS has been deprecated even by its own creators... so that's a bad example.
But don't you remember -- AngularJS was (if you took certain people at their word) the absolute shit some 4-5 years ago (that's slang usage of "the shit", as in "something really, really good you just have to get into, man"). Whereas now it's... well somehow no one wants boast about using Angular anymore, do they?
That's why it's such a good example of what I'm talking about.
Re: Choose boring employees
#38Earlier quoted context omitted.
The app I'm mentioning was pre-Webpack days, like 4-5 years ago. Just using KnockoutJS...which has no dependencies. It made me realize that tools can dramatically impact my output as a developer. Dependencies can sometimes be a pain in the ass to manage...but they are a huge net positive for productivity. When the choice is between downloading a battle-tested autocomplete package written and maintained by someone lik…
Right -- moral of the story being, one needs to evaluate any given framework import choice on its intrinsic attributes , pro and con. Not simply on how new and shiny it is. And potential collaborators and colleagues, likewise. Just give me people who are solid in the better practices of whatever language they use (even if it's Java or vanilla C) -- and reasonably aware of the current landscape (even if they chose not…
From that perspective, I see your point. I think Angular had an optimal sweet spot for the scope of applications it was good at building. Once you went past that point, it became unwieldy. I don't think you should chase something that's merely 12-24 months old if you're working on production code for a big product. But to some folks, using Golang or Node.js is considered "hipster" even though those technologies have been out now for many years and have proven themselves at scale at large companies. I wouldn't have suggested using Node in 2010, but in 2017, it's a mature choice. And letting your team use something like Go or Node over Java isn't going to kill you and you may very well see productivity gains and recruiting gains.
Re: Choose boring employees
#39Tech choices matter. The industry evolves and all of this experimentation in languages, frameworks, tooling, and libraries has led to real productivity gains. 10X developers may be rare...but I don't think it's so rare to see 10X productivity gains when it comes to tech stacks. For example, a company who runs their own servers manually can see dramatic improvements in productivity and agility if they move to a newer…
> 10X developers may be rare...but I don't think it's so rare to see 10X productivity gains when it comes to tech stacks.
When did this happen? I'm certainly not 10 times more productive than I was 10 years ago. In terms of productivity I think the web is still catching up with what was state of the art productivity for desktop applications 10 years ago, and that was when I was writing in "low level" languages.
Re: Choose boring employees
#40Earlier quoted context omitted.
I built an private side project app that was in use at of the major brokers. I built it in react redux, because I thought it would raise "my" value. I've had to rebuild that shit more times than I care to admit. Imho for a small dev shop picking react is a stupid choice. For a small dev shop picking node in the backend is IMHO also a stupid choice. I could go on with the list, but I'm going to stop knowing that I wil…
If react/njs is a mistake for web side projects, what would be a good alternative?
Just HTML and CSS, with some occasional JS to make things nicer?