As a developer, we all start from somewhere. And when we started, we really sucked. But since we didn't know anything then, there was nothing to lose and everything to gain. That's the Day 1 mentality.
As we work through the ranks, we become more knowledgeable. At this stage, it's so easy to stay in the familiar and keep doing the same thing. If you've been doing Ruby on Rails for 5 years and are in a Ruby on Rails tech company (as I was), there is no reason to study other languages. You can just keep coding Ruby on Rails the same way, and the paycheck arrives at the end of the month.
If all you have is a hammer, then everything is a nail
By not exploring other programming languages/technologies, you are closing yourself off to their possibilities. Each programming language specializes in some sort of problem area.
- Ruby is really great for web development.
- Python: is more versatile. It is great for data science, machine learning, scripting, and web development.
- NodeJS: is great for web development. It allows you to code your frontend and backend codebase in the same base programming language: JavaScript.
By using Ruby to do everything, we are using a blunt tool to address different problems that other programming languages could have better addressed.
So why not use another programming language?
It's easy to say, "okay, we are going to use Python" for this task. But when no one in the team has coded Python before, there's a being tradeoff made. Starting over a new language takes time, and developers will eventually make mistakes as they start off. And these mistakes can be potentially costly.
At the core of this hesitation are fear and laziness. Fear of making a mistake that can potentially cost the business. And laziness of making sure that those mistakes don't happen.
What happens is a sort of complacency that's self-reinforcing. The more we don't try out new things, the more we build on the old tech. The more things we build on the old tech, the more we have to lose if we change it.
Day 1 Mentality
While we can't revert to our foolish state when we started, we can take the mentality we had back then and apply some of it now. We don't need to dive in recklessly and make all of our developers do Python all of a sudden. But we can dive in smartly.
We can define the feature pipeline and identify where our current tool (Ruby) doesn't quite fit. We assign a person to learn Python and find a small project (to be deployed in production) that uses Python. As the team gains confidence coding in Python, we roll that out for more projects.
With the Day 1 mentality, we don't accept the reason "it's been done the same way before, it's going to take much effort to change it" for not using the best tool for the project. We challenge assumptions we hold. Is this really the best tool for the task? If not, what's stopping us from using it?
My Day 1 Mentality Journey
I have been a Ruby developer for 6 years now. When I joined my current employer last year, I had to learn Python. This year, my current personal project is to re-learn JavaScript (specifically, ES6) and develop web applications with NodeJS and Express.
I'm not quite there yet, but I'm learning fast. It's a bit dry going over the basics again: ifs, loops, functions, objects. But I'm actually learning something new. Studying the fundamentals of ES6, I'm learning how JavaScript differs in its approach to programming as Ruby and Python. It's actually given me a richer appreciation of all 3 programming languages.
Don't get me wrong. It's a lot of work. And I have to apply NodeJS for my next project. But it pays off because over the long run, I know I'm using the best tool for the job.
How about you? When was the last time you let yourself be a beginner?
Photo by Jukan Tateisi on Unsplash
Top comments (10)
I think you should always use the beginner attitude when programming. Never assume you master the topic and always assume there is something there you don't know 😊
Agreed! Acting like we have already mastered the topic closes us out from knowing more and learning more about the topic. There's always something to learn, at every step of mastery.
A year ago when I took my university’s Introduction to Programming course (Python) after already having learned Python before. So much imposter syndrome but understood programming concepts I thought I knew much better after it! 😄
When I was starting out, I tried the code-it-and-hack-it approach. Just googling my way through a problem and eventually, I'll build a complete toolset in coding. I did that for Ruby when I was studying Ruby on Rails. But I think formally learning a language allows us to be more aware of the nuisances of each programming construct.
That’s great! I enjoy learning frameworks the code-it-hack-it approach, and like the formality of learning programming languages formally. I’d like to try the code-it-hack-it approach for language learning though - sounds like a great way to learn to be creative with the possibilities and limitations of learning a new programming language 🙌🏼
Hi Amelia, I agree with your comment! Back when I was a pure Rubyist, we did a recommender engine in Ruby so we can just put it in the same code base as our main web app. It could have been better done with Python and its rich set of libraries like numpy.
I guess this Day 1 mentality also comes hand in hand with the microservices architecture. If we force everything to be in one system (such as a monolith Ruby on Rails web app), we are locked in using that technology.
I have the same experience just recently, this post speaks a lot to me. Tech is always evolving. We’re not limited to a specific language especially if it’s not the best tool to use with what we want to build. It’s loads of fun to explore new languages!
Indeed! With the microservices architecture, no need to keep everything on the same programming language. We now have flexibility to apply the best tool for the job
Hm, I don't think there's a week they goes by without exploring a new tool / language. Sometimes I revisit attempts. Nice stories to tell.
Indeed! This keeps tech exciting and we get to have some base knowledge when deciding between tools when the time comes