Hacker News Reader

> knowing about them was his primary signal for someone's overall competence

I don't know if it's the primary signal, but I think you need a balanced team. It's a good idea to have at least one person on your team who's staying on top of what's going on in the front-end community. But you have to be careful that person isn't blindly trying to apply every trend in your product, e.g. resume driven development.

This is a double edged sword unless you plan to allow them room to experiment. If all the work is in older technologies with no short term or middle term plan to upgrade, you will be hiring people who aren't going to be satisfied with the day to day duties and looking to change teams to a team who is using new things or leave. I think teams being honest and self critical about what their actual needs and day to day operations include is an important part of figuring out what skill sets should be on the team. Too much optimism leads to constant turn over.

> you will be hiring people who aren't going to be satisfied with the day to day duties and looking to change teams to a team who is using new things or leave

I don't know about this. I've been able to convince several developers to put down their shiny in favor of trying out some classic options. They seem to enjoy their newly-discovered traction. Progress feels good regardless of how you're achieving it after a while.

I did have to provide starting points & patterns, but it didn't seem to take much. I think they key is proving the value around why the old tools are (likely) better. Just lecturing a young person verbally about this and that is almost certain to send them even deeper into their rabbit hole.

If the mission is vague with uncertain upside associated with completion, you will absolutely find everyone fucking off in different directions as convenient. If you somehow frame the mission more like "ship by Christmas and everyone gets a 50k bonus", you can usually convince even the biggest 'not my job' assholes to adapt to changing realities.

Leadership is at the heart of why some companies are simple and others are running a technological clown show.

> you will be hiring people who aren't going to be satisfied with the day to day duties and looking to change teams to a team who is using new things or leave

Awesome. There are plenty of programmers who aren’t magpies distracted by shiny trinkets. I hope they get jobs. They can take the seats of those people who can’t bear not wasting time on the next new fad.

> It's a good idea to have at least one person on your team who's staying on top of what's going on in the front-end community.

Keep your friends close and your enemies closer.

>They hired a lot of "smart" developers, but they also took forever to ship anything.

Oh man does this resonate with me. Some of the "smartest" people we've hired have also been the slowest to deliver as they waffle and perfect and theorize and play with the tasks they have.

But then their playtime projects may turn into your next big product :)

That's something I didn't get for a long time

There is a difference between being smart and effective

I love the word effective and use it all the time.

It almost immediately gets rid of a lot of idealism.

Yep, more and more I think of the engineers I want on my team as "product engineers" over software engineers.

Overengineering is the devil

My go-to line is "I don't like working with geniuses, they're idiots."

Of course I don't actually think that, but there does seem to be a kind of parochial navel-gazing that comes with the high intellect territory, and in tech that manifests itself in absurdly over-engineered solutions.

> The team lead explained that knowing about them was his primary signal for someone's overall competence.

God help us.

> God help us.

Good luck, I think God is too busy refactoring his Perl code.

I think we both know it’s all lisp.

The worst thing about configuring emacs is when you accidentally create a pocket universe and now you have to keep that process running.

https://xkcd.com/224/

> "Truly, this was the language from which the Gods wrought the universe."

> "I mean, ostensibly, yes. Honestly, we hacked most of it together with Perl."

Does God write in Perl 5 or 6?

Black holes look like million dollar mistakes so probably something else, but the rest keeps working so probably not a monolith.

I feel like buzzword bingo in conferences is unavoidable.

The three easiest ways to get someone's attention in a title are: being a well known speaker, talking about a giant project, or talking about a trend.

As much as there is value in "tricks to avoid false negatives during CI" it just isn't as catchy.

I don't blame conferences for that. Conferences should (often) be a good place for more out there ideas, more experiments, experience sharing with new ideas, etc. It's the fault of viewers for thinking "I'm gonna do this thing without really evaluating it for my use case", which is a generally large problem in tech.

I think certain companies / people tend to dominate conference topics.

Most developers / teams / companies are just working rather than doing conferences. There's a whole world of development that is sort of opaque / assumed to be backwards.

Disclosure that I'm closer to full stack/generalist than frontend engineer.

Have you tried not going to conferences? I'm saying that with a good bit of sarcasm, but frankly look at where a lot of these things occur and who speaks at them. They occur in huge cities that curiously have beaucoup tech companies; companies that we know incentivize promotion based on things like "personal brand" and new project development as opposed to impact. Companies that often time give lots of money to those same conferences.

My point here is that conferences today are inherently inorganic and you'd get a lot more value reading long form blogs and going to meet ups to talk to people about the curious problems they have.

Also, those sexy companies want you to use the hot new thing because they’re selling the pickaxes. AWS sponsor a lot of educational platforms and conferences on cloud for a reason, for example.

I would argue that you should do the opposite.

Ask, "Pick a popular buzzword that you think is often a bad idea. Name it, explain what it was, explain why people like it, then explain why it is often a bad idea."

If they hesitate, reassure them, "It will be fine even if I disagree with you. I just want to see that you can think for yourself."

> This has been my experience with conferences lately: Way too much emphasis on the next big trend, to the point of being counterproductive for actually getting work done

I've been going to tech conferences for 25 years. This isn't a new new trend. :-)

> lately

always has been dot jpeg

I remember GlueCon 2012, just wall-to-wall NoSQL hype, with a dash of microservices on top. Anyone who ran home and implemented stuff from those talks was absolutely wasting their time (me included).