Why You Should Always Blindly Chase Industry Trends
Look I know you're here for the train wreck but there's logistical stuff we have to cover first.
"Are we really engineers" video now available
Here. tl;dr I interviewed 17 people who used to work as "proper" engineers and switched to software engineering, and had them compare and contrast their relative experiences. I'm not done with the project, but that draft is still pretty good, so give it a watch!
One slot remaining for TLA+ workshop
Here. Use the code [redacted] for $600 off!
Why You Should Always Blindly Chase Industry Trends
My job involves a lot of persuasive writing. I sometimes do writing exercises where I try to argue for something I completely disagree with. It's a good way to practice rhetorical skills.
Also, because I am very silly, I like defending things that no sane person would believe. It's more challenging and more fun to do. Everybody already knows that we shouldn't mindlessly chase industry trends, so that's what I'm going to defend. Not only is trend-chasing a good use of your time, but that it's a great use of your time, even if the trend is way outside your software niche. Like if I was taking this advice, it's not enough for me to chase trends in formal methods, but also in Agile, game development, Internet of Things, blockchains, JVM, etc.
Disclaimers
I don't actually believe this.
I didn't put a whole lot of time into this, no more than three or four hours. While the goal was to write a persuasive argument for trend-chasing, the purpose was to get more writing practice. I stopped once I felt it was no longer doing that for me.
Again, this is all purely a rhetorical exercise. I opted for being persuasive instead of being rigorous. It's possible to be both, but that would take a lot longer than I was willing to spend.
Technical Benefits
Reasons why blindly chasing industry trends will make you a better programmer.
Seeing the forest from the trees
The more things you learn, the more you're going to see the underlying patterns between them. When people talk about learning the "fundamentals", they assume there is an abstract idea of what a "fundamental" is that needs to be approached abstractly. But people learn better by inducting on examples. You're going to get a better sense of what "orchestration" fundamentally is if you've worked with a lot of different orchestration tools. You'll have a better understanding of "state" if you've managed it in imperative, functional, and synchronous languages.
Learning more tools will also give you a better sense of specific domains. How is Vue different from React? What are the design decisions that caused those differences? What were the contexts that led to those design decisions? What parts of Backbone did they keep and what parts did they reject? As an outsider looking in, you have at best a surface level understanding of this. But if you know all three, because you chased all three, then you can deeply understand the context.
One example I really like: Flux is the new WndProc. The author is able to compare 2015 web technology to 1985 UI models. And he's just a well-adjusted individual. Imagine the parallels an extreme trend-chaser would see.
Cross-Pollination
The more distinct ideas you can keep your head, the more relationships you are going to notice between them. You will be able to transplant ideas from one context into another to make them both better. This kind of mixing tends to happen a lot more with programming languages, as people are expected to learn multiple programming languages, but can also happen between tools or disciplines.
Find your passion
Some trends aren't going to appeal to you. That's fine. Some of them will be interesting and potentially useful, a good thing to keep in your back pocket. And a rare few will write themselves in fire on the inside of your skull.
This is what happened with me and formal methods. I did never heard of it before, I didn't expect it to be anything more than an interesting tool, and then it completely took over my life. My life would be completely different if I hadn't explored it. Maybe my life would have changed just as much if I had tried embedded hardware first, or Wardley mapping, or deep learning. But I suspect that whatever grabbed me would've been very unlike what I had been doing until then, which was Rails/Webdev/AWS.
If there's something out there that really clicks with you, there's no guarantee it's going to be something you'd encounter in your day-to-day career. That means exploring a lot of different crannies of software, which you can do by blindly chasing industry trends.
More Practice
This benefit is more down-to-earth than the others. Constant practice and learning makes us better at programming. It's hard to practice something if you already know it well. This is why people in the extreme programming community write "kata" exercises: without a directed goal, people won't consciously practice the skills. By chasing industry trends, you're constantly putting yourself back in the position of the beginner. This means you spend more time practicing and absorbing knowledge, which makes you better.
Career Benefits
Reasons why blindly chasing industry trends will make you more money.
Employability
The more trends you chase, the more employable you are. You're more quasi-qualified to apply to more jobs. Even if you only have a surface level understanding of the requisite technologies, you can brush up in the time in between the application and the interview. It's easier to build if the foundation is already there.
Does this sound too tongue-in-cheek? It's not. If you look at the average programmer's salary history, the majority of pay raises happen when they switch jobs. A person who works two years in job one and then switches to job two will have a higher salary than a person who works for four years in job one. If you're trying to strategically maximize your wealth then you have to change jobs.
It would be tongue-in-cheek to say that blindly chasing industry trends sets you up to work on legacy codebases later. As trends die out, companies that jumped on them are now stuck with obsolete technology a dwindling number of people know. Would be except that working on obsolete tech stacks is insanely lucrative. Just ask COBOL programmers.
Social Capital
Let's talk about social capital.
Social capital is our reputation, who we know, our measure of respect, the credibility we have. It's why well-connected people have an easier time finding jobs, getting support for their projects, knowing just who to introduce you to help you reach your own goals. When I started interviewing engineering crossovers, I just tweeted out my request and people started responding. They started sharing it with relevant friends who didn't know about me. That's social capital.
Programmers are often deeply mistrustful of social capital as a tool, usually associating it with slimy "networking" or cults of personality. But this is an overreaction akin to saying that because machine learning is easily biased we should stop all programming. Social capital is a fundamental part of any sort of human endeavor and learning to build and use it is critical for getting things done.
How we build and use social capital is an immensely complex topic and not one I can really cover. But one relevant bit is that it's not a single value: different communities have different levels of respect for a person. I wouldn't expect Robert Martin to be very welcome at LambdaConf! But you never know which social groups are the ones that will be most useful to be in, as this is often highly dependent on the individuals within those groups. Building up a lot of social capital then means building respect in a lot of distinct communities.
Chasing every industry trend exposes you to a lot of communities and gives you opportunities to build social capital in all of them. Within each community you can also take advantage of your reputation as the person who knows everything: the Kubernetes folks will know you as the person who knows embedded hardware, while the embedded people will know you as someone who also knows Kubernetes.
Also, the more social capital you have, the easier it is to get good jobs. It's all a feedback loop.
Conferences
The more trends you know, the more conferences you can speak at. You don't necessarily need to know the trend super well to be a speaker; charisma and notability can take you a long way here. Being a reliable speaker opens up a lot of opportunities:
- Conferences often happen in interesting places you get to tour
- Speaking at conferences can quickly build a lot of social capital
- You make a lot of new friends
- Once you're more well known you can start charging speaker fees
- Hallway track.
The last one is a biggie. A lot of the most interesting and influential discussions at conferences happen outside of the talks. They're between the conference goers in the common spaces. The hallway track is where you learn what the next big thing is and what will be the thing after the next big thing. It's where you learn all of the exotic tech and use cases for the trend you've never heard of before. It's where you find out social gossip and the actual experiences of people using tech in anger. Most veteran con goers I know will make sure to block time out in conferences to hang around the hallways.
The more trends you chase, the more conferences you can choose to go to, and the more hallway track you can experience. That puts you in a better place to be well-connected to the future of software in all the various forms it takes.
Personal Benefits
Reasons why blindly chasing industry trends will make you better in a loosy-goosy humanities way.
Learning how to learn
The problem with blindly chasing industry trends is that there's a lot of industry trends out there. It's not enough to just spend a lot of time learning: you need to get better at the act of learning itself. You need to develop better skills for researching, studying, reviewing, practicing. These are universally helpful skills, but we tend not to develop them unless it's absolutely necessary.
Think back to college. You probably don't learn topics as fast now as you did then. Part of this is because you had more time back then. But another, less discussed part is that you're now rusty: it's been a long time since you were motivated to learn things that fast. Your skills at learning have atrophied. Chasing trends is a way to get them back: it gives you a variety of topics that you want to learn at a fairly rapid pace. Good studying habits are important again, so you can develop good study habits.
When it's time to learn something it actually matters, you'll be much better equipped to do so than people who've let their research skills lie fallow.
Understanding hype
Trends don't appear in a vacuum. When everybody starts using, say, NoSQL, it's not because everybody independently look at NoSQL and decided it fit their needs. And "everybody's needs changed" wasn't the reason that NoSQL fell out of favor. The hype surrounding something is independent of its utility.
I mentioned earlier that it's easier to see fundamental principles if you have concrete examples. This applies here, too. Every trend is a concrete example of the abstract concept of hype. By exploring trends, you learn more about the nature of hype itself.
That is an incredibly valuable scale. Seeing the mechanisms of hype makes it easier to untangle the value of something from the buzz around it. It lets you see how trends start, crest, and die. You see what makes people more willing to believe versus more willing to mock. Instead of seeing the forest for the trees, you see the whole ecology.
This isn't magic, hype is a social dynamic, and social dynamics are hard. Anybody who says they completely understand a social dynamic work is lying or deluded. But it's possible to understand fragments of it, build intuition for it without being able to systematize it. That intuition is worth sweating for.
Conclusion
All of these arguments are flawed, don't trust any of this, it was purely a rhetorical exercise, please don't kill me.
If you're reading this on the web, you can subscribe here. Updates are once a week. My main website is here.
My new book, Logic for Programmers, is now in early access! Get it here.