Whats app everybody!!!!!!!!!!
Sorry I was a little too excited, What's up everybody. How's everyone doing? I am fine too. OMG, thanks for asking 💕❤
So, If you clicked on this blog I'm sure you also want to be an awesome developer and improve yourself just like every developer wants to be including me. I know when we start our wanna-be "A Software Developer" journey how hard we try to learn things, create projects, looking for freelance work, and preparing for interviews to get a job as a Developer.
You land a job by putting the hours and hard work. You are extremely happy and proud of yourself for achieving your goal of becoming a Software Developer. But till this time you had only worked from your home sitting in your bedroom not knowing what Pair Programming is, How to rebase your branch, What is a Pull Request, What is Daily Standup, What is Story Grooming, What is a Jira Board, I have to write documentation of code? and Why the hell is everyone writing unit tests for their code etc. OH GOD, I couldn't breathe writing the previous sentence.
So, the gist here is that you became a Software Developer but now you need to improve yourself as a Software Developer. And this starts with finding a mentor, who will guide you on the dark path of becoming a Software Developer with his Torch of experience. But the sad reality is that not every developer finds an experienced mentor at his/her workplace.
But Don't Worry, I saw this tweet thread from Sarah Dayan in which she shares 10 takes from his software development journey after working in the industry for 10 years (Seriously 10 years 🤯, Btw Sarah once again fan of your website). So I liked the thread very much and thought why not create a post sharing those 10 points of her with all the dev community so we can also apply these things into our development journey.
So, Let's jump straight into Sarah 10 points from her 10 years journey in the software industry.
1. Quality of experience
1. Years of experience don’t mean anything (without quality of experience) 📈
Doing stuff for a long time doesn’t mean you’re getting better.
Stagnation is real. If you’re not actively trying to improve, time doesn’t make it happen automatically.16:22 PM - 26 Jul 2020
492
3671
2. Feedback and mentoring
2. Having coworkers is invaluable 👥
Not matter how much of a lone wolf you think you are, you won’t grow as fast alone as with teammates.
Feedback and mentoring (giving and receiving) are a privilege. Without them, you’re operating at a mere fraction of what you could be.16:22 PM - 26 Jul 2020
3. Make educated choices
3. Identifying with technical choices brings nothing 🛠
It’s fine to like specific tech and want to be part of a club. But it doesn’t make you better than anyone.
Be careful of the golden hammer bias. You’re a problem solver, not a sandwich board man. Make educated choices.16:22 PM - 26 Jul 2020
4. Don't follow the hype
4. On many subjects, there are no absolute truths 👁
The Internet is filled with opinions. Look at it as food for thought, not gospel.
Parroting the latest thing you read doesn’t make you smart. Consume content to stay current, but also keep a critical mind.16:22 PM - 26 Jul 2020
5. Basics are important
5. Nothing is beyond your reach when you master the basics 📚
You can start wherever you want. But if you’re finding yourself struggling a lot, it might be because you lack strong foundations.
New and fancy stuff is based on the basics. Mastering them lets you see the matrix.16:22 PM - 26 Jul 2020
6. Burnout is real
6. Burnout is real 😓
Coding is mentally demanding. The constant stream of information is overwhelming. The pressure of staying current is heavy. The fear of job security disappearing one day is legitimate.
Depression is as real as COVID-19. It’s okay, and help exists.16:23 PM - 26 Jul 2020
7. Communication is key
7. Seniority isn’t about being the best coder 👩💻
If you think you should be senior because you’re a technical beast, you’re missing the point.
Seniority is about experience, impact, and efficiency. Seniors are usually technicially proficient, but soft skills play a huge role.16:23 PM - 26 Jul 2020
8. Diversity is crucial
8. Diversity is crucial 👩🏻🦱🧕🏽🧔🏿🧑🏼🦰
Believing in meritocracy is like saying that kids who are good get presents for Christmas.
Diversifying culture in tech is necessary, and must be an active process.
Start here: dev.to/maxart2501/on-…16:23 PM - 26 Jul 2020
9. Quantity is as important as quality
9. Quantity is as important as quality 🧮
As cliché as it might sound, you won’t get better by polishing forever. Experience and knowledge mostly come from confronting what you do to the outside world.
The more you experiment, the less intimidating it will feel to ship.16:23 PM - 26 Jul 2020
10. Connections and relationships.
10. Who you know is as important as what you know 🗺
There are humans behind computers. It’s not just about hard skills. It’s also about making connections and fostering relationships.
You don’t have to become Twitter famous, but reaching out to people goes a long way.16:23 PM - 26 Jul 2020
Well, this was a fun blog. I learned a lot from this thread, and I hope you found this interesting too. Thank you so much, Sarah, for sharing your experience with the community 💕❤.
Well, enough of chatting with you guys, I am going to write unit tests for my even-odd program (Below is the code) ;)
Stay safe guys, Peace ☮️.
Top comments (22)
Can I add two incredibly cynical things to the list?
First, never use version X.0 of anything. Let the early adopters find the egregious bugs.
Second, if some tool suddenly becomes wildly popular don't look at it immediately. Make a note in your diary two years down the line to have a look at it. Separating hype from quality takes time and, just like with version X.0, your time is better spent letting other people do that for you.
"Separating hype from quality takes time" - yeah, but at the same time if you do go by the quality of experience and learning, there's no harm in being part of the process that separates hype from quality. If all you care about is the grind of delivering someone else's ideas, sure ... you can get by on letting others be at the forefront of a new technology.
It's a risk, sure, to get involved with something that burns out as a hype but if you're a technologist then even that has a positive spin since if you do it often enough, you already have what it takes to not be tied down on a particular 'thing'.
I'd rather spend my time creating my own overhyped nonsense instead of figuring out what other overhyped nonsense is any good.
Definitely this is by far the best generally valid advice, everyone should create their own overhyped tech nonsense, disregard what anyone else is doing unless someone else validates it first and happily live in their own bubble which they rule. If presidents can do it, so can everyone else.
You forgot /s
Yeah, I hate it when that happens ;)
Addendum to your "Second": if some tool becomes wildly popular suddenly, it's usually shit. (This reinforces the "make a note to look at it two years down the line").
This is great advice, for a stable-job kind of person (i.e. looking for a good work-life balance). If you're hired, preferably in an already established company, then follow this advice and you'll stay away from trouble forever <3.
But life is dull with no trouble at all! You'll end up writing monolithic backends using Perl in 2020 😅. Not that there's something wrong with Perl per se, but we have better options for that today.
Also, when trying to bring something new to the market, or if you're really into continuous learning, using new techs can help your company/personal brand.
You'll be among the first to have know-how in a hopefully rising tech. As the hype grows, you'll have a very good position to negotiate from.
Of course, using x.0 (or betas/alphas) most of the times means actively participating to the product/library. This means effort, but also good opportunities to learn stuff.
Great advice, thankyou 🤗
Agree except I check back for a few months not years. Taking risks on new things is fine though. Otherwise we wouldn’t have iPhone with new parts etc but things do need vetting
The iPhone is a great example of not looking at anything hyped for two years. It took two years to become suitable for anyone except Apple fanboys. Version 1 had basically no internet - it couldn't do 3G - you couldn't copy n paste, you couldn't even add third party software. Version 2 was pitifully slow. Version 3, the 3GS, was the first really usable product. It came out ten days short of the second anniversary.
These are timeless advice. I love that. I'm a 10 years developer as well (20 years coding as a hobby), and I agree with everything.
But, as you said, it's not because I have 10 years of experience that I know what I'm talking about :D
I specifically agree with this:
Don't follow the hype.I think it's really true. My take on that: if developers focus on the fundamentals, they won't have to follow the hype. It will be easy for them to adapt to new technologies if they need to, because everything is built on these fundamentals.
Let's take programming languages: they look all very different, but if you look closer, mostly the syntax change. The big ideas are the same, and if we know these principles, it's way easier to adapt.
It's a bit a shameful plug, but I'm trying to write a blog about that, if somebody is interested: the timeless fundamentals and tools we should focus on.
Thanks for that!
Loved the post on The Art Of Learning For Software Developers ❤.. Awesome work keep it up 🚀
A somewhat cynical tip, but beware of managers. There are great one and there are awful ones. There are some that will burn you. There are some that will de-skill you. At the end of the day, your career is important; more so that the company you work for.
Your code would be much more readable with a switch statement
thanks man
Perfect! LGTM.
Ha ha ... Nice article.
Seriously, how do we check if the given number is odd or even? I don't think the approach in OP is well-designed.
If you're genuinely asking for the solution then below is a simple implementation
Wow, thanks for the nice solution!
Can you please share some experiences about how lack of diversity negatively impacted a project? That will really help drive the point home i think.