What have you learned as a developer that it's worth sharing with us?

Code City
1

Hi all :wave:

This post is a place for everyone to share insights with the community on anything you have learned that impacted you as a developer, whether in code review or in general, from a project task you had to overcome, a specific issue regarding a programming language, a success, failure (code review horror stories also count!), or any experience - everyone has an amazing story, and we’d love to hear yours.

Here everyone is a developer, engineer, and will likely have had different experiences - you can share what’s working for you, what you intend to try and get feedback from others - we can all learn from each other as we all have something to learn and to teach.

You can reply to this thread or start a topic with a specific title so we know what it is about :slight_smile: looking forward to hearing your stories!

5

Speaking from the junior side there are several things freshers should understand asap:

  1. DRY approach is a king. Programming is about automatisation, not about Ctrl+C, Ctrl+V.
  2. Learn-Practice, Learn-Practice instead of Learn-Learn-Learn-Practice. Tutorial Hell is a big problem of almost every newbie developer.
  3. Move from one code flow into separate functions. Move from one file into separate files if the project became bigger than usual.
  4. Build real-world project instead of dozens of small apps. You will face a lot of problems. Solving them will bring much more experience than jumping on the same place with small pet-projects.
4 Likes
6

This may be somewhat generic, but the most impacting thing I learned as a developer was to break down big/complex problems into smaller parts. And then, repeating the process over again until I got simple and straightforward “instructions” that I could instruct the computer to do.

If you learn to do this well, you’ll notice that you’ll start applying the same technique not only to coding but to everyday problems as well!

This gives you a great boost in problem solving skills, which is what the end goal of software development is all about.

3 Likes
7

@StasKlymenko nice insights there, thanks for sharing! And a great tip on point 4, it’s always good to have a side project going on, something that you care about, and nothing better than a real-world project, so you can also see it growing and the impact it can have. Thank you :muscle:

@paulo.ribeiro, does that have to do with the Separation of Concerns we talked about? :slight_smile: I know it’s a different case but I think this thought-process makes complete sense, even in real life, as you said it! An idea that I completely vouch for, thanks Paulo!

I also came across this sentence recently, "Write software as if your users were blind” which I think it’s pretty interesting, and also a reason why clean code is so important. Not sure what everyone here thinks about this, any thoughts?

2 Likes
8

Being a junior dev - now I understand the comparison very good (when you’re working on projects by the tutorial and when you’re building something like a real project). The difference is huge as there will not be any guide for you “how to create this thing”. No, please search and build it by yourself.
And that’s the step where the real experience came.

2 Likes
9

Yes, the “separation of concerns” has to do with how you break up your program into modules that have well-defined responsibilities or solve a specific problem. :+1:

This principle also applies very well to Technical Writing, and I’ve been using this approach to gradually improve the information architecture on the Codacy documentation. :bookmark_tabs:

1 Like
10

One thing that I’ve even pinned on my Twitter:

Advice for future developers: do not put one project in your shoulders, or do not carry the project in your shoulders. When you notice you are going to be overloaded, ask for help.

Another thing that I’ve learned a few years ago, was about “moving away from your comfort zone”. Used to work within a company where I was so in a “comfy zone” that I didn’t progress at all on it, was always doing the same old thing every now and then. After I knew my contract wasn’t going to be renewed it kind of made me realise I had to change and step out and learn new things, even if it wasn’t required. This way I could improve, not even my professional experience, but also where I was working.

2 Likes