Developer on Fire Episode 132: Odin Project creator Erik Trautman

Developer on Fire Episode 132: Odin Project creator Erik Trautman
0

#1

Here’s the podcast: http://developeronfire.com/episode-132-erik-trautman-quest-for-meaning

This was a great podcast that just came out today. I listened to it twice on double speed.

From 31:46, on Erik’s information diet:

“When I was first learning, I said turn on the firehose and said, just send everything at me. I’d spend hours reading Tech Crunch, Hacker News, Subreddits, and take as much information as I could possibly handle. That was useful because you do have to go through this phase where you see the edges of the landscape. But that’s not really a sustainable way to go about things. More and more, I’ve started stepping away from the firehose of information. All information is not created equal. There are empty calories. Instead of going out and reading everything I can, I try to be more collaborative, and have conversations with people who know about these topics, as opposed to taking an independent approach.”

I’m curious how many of your approach to learning about technology has shifted over the past years (months?) and whether you have found the “firehose” approach helpful.


#2

I would have had difficulty putting this into words on my own, but the firehose analogy really works to describe the way my information consumption habits have been changing. When you are new to a field of study you don’t know what you don’t know. Where does this bit of information fit in? Total immersion by standing in front of the firehose for an extended period of time does eventually build a mental scaffold or framework where you can place and hang new information in a context. Once that scaffold is in place you can step away from the firehose and start to selectively consume information because you can see that you need to fill in a hole on the bare wall here, and here, and here… So personally I’ve moved from the soaking wet phase into the going outside to stand in a brief shower phase. And I have to say its a more comfortable place to be!


#3

I’ve found I also operate in cycles that way: several months of curiosity about new frameworks, languages, technologies, followed by taking about twice as long to evaluate and integrate it into my own work patterns.

Anyone who drinks from the firehose all the time is likely spending all their time chasing after shiny new tech and not getting anything actually useful done.


#4

This is a great analogy! I definitely had the firehose on at full blast when I first started. Everything was new and exciting. I wanted to learn it all. But also, I really didn’t have a focus.

Nowadays, I pace my intake and also find myself a little more selective of what I decide to consume. There is just way too much tech out there to try to learn it all. Thank goodness for abstractions :nerd_face:.


#5

I have seen more articles and discussions about a movement back towards specialization. So being Full Stack may not be so easy or suggested in the future. So maybe as the fire hose keeps getting bigger with more flow, will Front End and Back End need to focus more again on their own areas? Or are we all to learn it ALL?


#6

The notion you can learn it all is mythical even today, and as the ecosystem grows, that will become more apparent. Some devs will specialize, others will be generalists, but even the generalists will be so with a handful of frameworks and dev tools. It’s the sign of a maturing language and platform when that’s the case.


#7

Naturally, the more you learn the better. As with most endeavors, it comes down to a question of priorities. Free Code Camp’s curriculum is the most important “low hanging fruit”. Years into your career, you will still be learning, but you’ll be learning more and more esoteric topics that pack less marginal benefit VS time spent learning.


#8

I am the host of the show featuring Erik cited here.

Erik was fantastic on the show and so much to take away from his philosophical approach to everything. I loved having the conversation with him. I’ve listened multiple times over the course of editing and writing show notes and ultimately listening to the final product.

Thanks for sharing it, @QuincyLarson.

Early in my career, I had a bit of the firehose approach to reading as much as possible. In those days, finding a book on a topics was the way to learn it (which worked because release cycles on the technology covered in the book were about as frequent as books get published). Now it’s much easier to find current information via blogs and podcasts and such, and it’s a good thing because the tech is moving faster than ever.

Today I’ve come to the conclusion that the best way to learn is to start building something and finding something to read and emulate whenever I come across something I don’t know how to accomplish. That’s it. Work on a project and read when you’re stuck. Subscribe to podcasts and use Twitter as a source of finding things that should be checked out.

Having a resource like Stack Overflow, too, is amazing. Getting good answers to questions for which you can’t find the answer readily available and having a place to answer some questions to test your own understanding is huge for the learning process.

Erik’s process/progression that I summarized as Consumption -> Action -> Interaction is pretty awesome and goes right to the heart of effective learning.


#9

Specialization is important and beneficial. I wouldn’t look at it so much as specializing on front-end vs back-end, though. Full-stack development is still a competency you need to have or you will be really limited in what you can do. It’s fine to like working in the browser more than on the server or the other way around and being better and deeper at one than the other, but having basic competency in both is necessary. Node is nice because it doesn’t require different languages for different places.

I like to think of specialization in terms of the types of problems you tackle and the approaches you take. When just learning to code, high-minded ideas like architectural approaches, including Domain-Driven Design are probably not on the radar. Still, the essence of deep collaboration in the domain of the businesses you serve rather than just being a code monkey is something best embraced from the start.

Specializing in distributed systems, or community websites, or Agile methodologies are good places for niches.


#10

Thank you for the great and well thought out response. I agree NodeJS is a perfect focus area, as it is seen as being the top back-end technology for the foreseeable future, and npm the most used package manager for web developers.
As a beginner I have already found myself fascinated with front-end design, and am spending more time with Google Material Design than anything else currently. It just keeps me excited more than other parts of web development. But being well rounded is essential, and I am happy to read your post and am going to ensure that I am making an effort to be proficient in all aspects of front and back - end technologies, even if I do like the design aspects more and more :blush:


#11

@raelyard @QuincyLarson Thanks for giving my humble words a listen and pulling out a nugget of value from it :slight_smile: I like the structure that Dave proposed for the theory – Consumption >> Action >> Interaction. As others have highlighted, the key is figuring out when it’s time to turn the spigot down a bit and progress from one to another. Good luck with the learning ahead!!!


#12

Hi Erik,

Awesome! It’s an honor to have you here.

Yes - I agree. It’s important to frequently evaluate the return-on-invested-time of an activity, which may start out high but diminish over time.

When I was starting out, I read Hacker News every day, and that gave me exposure to a wide range of topics. But like you, I reached a point where such breadth of information was no longer as helpful, and I had to narrow my focus.