DEV Community

Cover image for 10 tips from A 10 years experienced Developer
Programmer Things
Programmer Things

Posted on

10 tips from A 10 years experienced Developer

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.

Alt Text

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

2. Feedback and mentoring

3. Make educated choices

4. Don't follow the hype

5. Basics are important

6. Burnout is real

7. Communication is key

8. Diversity is crucial

9. Quantity is as important as quality

10. Connections and relationships.

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) ;)

Alt Text

Stay safe guys, Peace ☮️.

Top comments (22)

Collapse
 
phantas0s profile image
Matthieu Cneude

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!

Collapse
 
programmerthings profile image
Programmer Things

Loved the post on The Art Of Learning For Software Developers ❤.. Awesome work keep it up 🚀

Collapse
 
drhyde profile image
David Cantrell

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.

Collapse
 
andreidascalu profile image
Andrei Dascalu

"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'.

Collapse
 
drhyde profile image
David Cantrell

I'd rather spend my time creating my own overhyped nonsense instead of figuring out what other overhyped nonsense is any good.

Thread Thread
 
andreidascalu profile image
Andrei Dascalu

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.

Thread Thread
 
rad_val_ profile image
Valentin Radu

You forgot /s

Thread Thread
 
andreidascalu profile image
Andrei Dascalu

Yeah, I hate it when that happens ;)

Collapse
 
zilti_500 profile image
Daniel Ziltener

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").

Collapse
 
rad_val_ profile image
Valentin Radu • Edited

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.

Collapse
 
programmerthings profile image
Programmer Things

Great advice, thankyou 🤗

Collapse
 
mrjjwright profile image
John Wright • Edited

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

Collapse
 
drhyde profile image
David Cantrell

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.

Collapse
 
eonuk profile image
eonuk

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.

Collapse
 
cullophid profile image
Andreas Møller

Your code would be much more readable with a switch statement

Collapse
 
programmerthings profile image
Programmer Things • Edited

thanks man

Alt Text

Collapse
 
cullophid profile image
Andreas Møller

Perfect! LGTM.

Collapse
 
bravemaster619 profile image
bravemaster619 • Edited

Seriously, how do we check if the given number is odd or even? I don't think the approach in OP is well-designed.

Collapse
 
programmerthings profile image
Programmer Things • Edited

If you're genuinely asking for the solution then below is a simple implementation

Alt Text

Collapse
 
bravemaster619 profile image
bravemaster619

Wow, thanks for the nice solution!

Collapse
 
vjnvisakh profile image
Visakh Vijayan

Ha ha ... Nice article.

Collapse
 
terpinmd profile image
terpinmd

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.