Hi everyone!
I'm Fernando, long-time user of dev.to, and while I haven't been able to post recently, that's just because I've been crazy busy trying to work on one particular project I'm very excited about.
For the past 6 months or so, I've been working with the folks at @manningbooks to create a book that could act as a bible for any new developer joining our ranks.
What do I mean by "bible"? Essentially I wanted newcomers to understand what it meant to be a developer, how to deal with the usual hurdles of our profession and what to expect from the experience of working as a developer.
You see, I've met people joining our ranks simply because they know the "pay is good", but really have no idea what to expect from our industry.
I've met others coming with completely unrelated backgrounds hoping to turn their lives around and make a living for themselves through coding.
But just like with everything in life, if your expectations aren't set correctly, you're only going to be disappointed, so I want this book to be that for them (amongst other things).
But I need your help, the book's not ready, and while it's already halfway there, there is still time for me to go back and edit any of the chapters, and add any information you think it could help others, so I'm essentially asking for feedback here.
Right now, the book is out on Manning's Early Access Program (MEAP), which means that if you get it, you'll right now get the first 3 chapters, and once the new ones start getting published, you'll be getting them as well. Through their site, you can provide feedback and leave your comments (this is what I need to make the best book possible).
What's in the book?
Now, I'm sure you're wondering what's inside, what kind of information have I deemed worthy of "the bible for new developers", so let me share the ToC for the book, hopefully that'll give you a better idea.
The topics covered are:
- What you need to be a developer. There is a lot of misconception around what is needed to become a developer. I personally don't think it's about going to college or having 50 side projects before you get your first job. In fact (spoiler alert), I don't think any tech knowledge is required to be a good developer, that will come with the trade on its own.
- Learning how to code (tips&tricks). The book doesn't cover basic programming knowledge, instead, it'll cover recommendations on best practices around commenting code, usual traps such as overengineering, early optimization and the like.
- Unit testing. This is such as basic and cross-tech topic that I had to include it. Since I'm not focusing on one particular language, this section covers the generic approach at Unit testing and best practices around it.
- Refactoring. Same with refactoring, it's not about doing it with one programming language, but rather, about understanding what it is, when you should do it, and the best practices around it.
- Work-life balance. We all know that coding can become your life, however, that can also be a bad thing, it can lead to burnout and thus bad performance at the workplace. This section covers some topics around understanding how to avoid burnout.
- Getting past the interview. This section is almost done and I had a lot of fun writing it. It covers everything you need to understand the tech job interview. Especially some tips around what you shouldn't be saying and what to listen for to understand if the job you're being offered is actually good or just a bunch of lies.
- Being a good team member. As part of our experience as developers, we can't really expect to be working alone, even as freelancers. This section will explain what it means to be a team player and how to code taking your colleagues (future and current) into consideration.
- Leading the team. Finally, because most of the time the usual "next step" for any developer is to start leading some teams, I'll end the book explaining what it means to be a team lead. Recommendations around it such as understanding that you can't be expected to be the guru inside your team, and covering the exact responsibilities of the team lead.
Interested yet? You can check out the book here
Now, a very important aspect to understand, is that this is not generic advice taken from internet.
I've been working inside the IT industry for the past 18 years and I've seen some sh*t.
I've written my share of terrible code, and I've been corrected multiple times. I've seen many horrible managers trying to micro-manage everyone and I've also seen great ones showing me how to grow without holding my hand.
The book covers my own experience around the above topics, my personal preferences when it comes to best practices and essentially everything I've seen that works.
What gives me the right to write this?
Great question, in fact, that's one that you should always ask when reading something someone else wrote. Internet is filled with people trying to teach others without actually knowing what they're talking about.
So here is a summary of me and my career so you get to know me a little bit and understand where this book is coming from.
As I said before, I've been working as part of the industry for 18 years, I started when I was 19, and I'm 37 right now.
I've done Web development working with PHP, RoR, Python, Javascript (vanilla most of it), HTML, CSS and Node.js. And then I made the jump into BigData and started marrying my previous experience with the ability to create scalable and highly available platforms. I've worked with Hadoop, Hive, Kafka and a plethora of other technologies that would be too boring to list here.
During that path, I eventually started leading technical teams, growing my soft skills and while I was doing that I also started to write, both tech articles as well as technical books.
I've written over 150 articles reaching more than 1million people in Medium (not my numbers, check out the image with the actual stat). And I've published 8 books so far (link to my Amazon profile because it's the only place where I have them all listed), most of them around Node.js and JavaScript, this would be the first one that covers more generic aspects of our profession.
I'm currently a Data Engineering Manager working for a big consulting firm, so while I don't have to code every day, I'm still very much in contact with developers trying to mentor them and help them grow in their career.
Am I alone in this?
I'm trying to help those getting started to understand what it means to be a developer and to give them the tools to succeed at this career. But I'm not the only one trying to do it.
There are plenty of other folks doing the same around here, such as @florinpop17 , @wesbos , @dthompsondev and others.
They're all doing work to help others, each one with their own skillset and I can't but look up to them and try to do the same, so this is my own grain of salt.
I would just love to complete this book with your help, making sure that the content I put inside makes sense to you if you're just getting started or if you've been through that process recently.
So to help with that idea, and because let's be honest, I also need the book to be sold to show the folks at Manning that the principle behind it is indeed useful for the community, here is a discount code you can use (I think it'll be valid until the 29th of June) for a 50% off price: mldoglio
Use that during check out and you'll get the discount.
That's it
That's it, that's the announcement, I'm writing a book for everyone that's either thinking about getting started and working as a dev, or those that have just joined our community and are trying to figure out how to fit it.
Get the book here and make sure you leave your thoughts either directly on their page, here in the comments, or reach out to me at fernando.doglio@gmail.com.
Top comments (1)
Hey Nate, that's very helpful advice.
I indeed already have something similar planned, but I'll keep an eye out when I get to writing that section to make sure I cover the "breaking down problems" part.
Cheers!