I’m a Software Engineer and it’s been about a decade since I’ve worked in this field, building end-to-end solutions of different kinds, mainly comprising Mobile Apps, Web apps, and API services.
There was a lot that I wasn’t familiar with when I started and I picked a lot of knowledge and wisdom as I moved along in that journey.
So I decided to document my learnings from this journey in a post so that anyone on the same path as mine can take away from it as a helpful guide.
Quick Disclaimer:
All the lessons/opinions mentioned in this post are entirely entitled to my personal field experience. I’ve mostly worked with small to medium-sized teams and companies throughout my career so far.
TLDR;
- Job Titles are irrelevant
- Target core Fundamentals, Concepts, and Knowledge
- Avoid Trends and Technology Fanatism
- Share your learnings and experiences
- Optimize your way of learning and educating yourself
- Communicate Effectively
- Naming is important
- Automated Unit Testing is important
- Master your craft, and get better at reading docs/manuals
- Take care of Yourself
Lesson 1: Job Titles are Irrelevant (Mostly)
You are a lagging measure of the work and value you deliver, you will be remembered by the value and experiences you deliver and the impact you make and not by your job titles. Hence job titles are meaningless.
Lesson 2: Target core Fundamentals, Concepts, and Knowledge
Fundamentals and core concepts are crucial when it comes to effective problem-solving and collaboration as an engineer. Surface-level tools and technologies can change or evolve, but the core fundamentals remain the same.
Targeting root-level concepts and knowledge first is a mental model for an engineer.
Target root-level concepts first and then move further from there.
For example:
Before learning Redux, MobX, Recoil, etc., or any other state management library, learn and master the concept of State and State Management for JavaScript applications in general and then pick any pre-built solution of your choice.
That way your fundamentals are more solid and will be able to get you far.
Lesson 3: Avoid Trends and Technology Fanatism
This is pretty much connected to the previous point I made, attaching yourself to a particular tool or technology, just because it’s cool or trendy is just limiting and it’s one pessimistic way of looking at the technology ecosystem.
Thinking that the tool or technology you’re using is the best or superior and the rest are trash is extremely toxic and limiting.
Sure you can pick a tool or tech to solve a problem if you feel comfortable, but there’s no need to be fanatic about it.
Just remember how good a framework or a technology is, it cannot help you out of your incompetency if you lack fundamentals. It will not fill the knowledge gaps for you and expose them at a certain point in time.
Lesson 4: Share your learnings and Experiences
Being an engineer you come across a lot of problems throughout time and build solutions, you should document your journey as you go in the form of content such as blogs, videos, etc.
This not only helps you keep track of your journey as an engineer but also helps you strengthen your concepts and knowledge.
Use this technique as a litmus test or validation of your learnings and knowledge, and write it down.
“Writing is nature’s way of exposing how flawed or sloppy your thinking is.”
— Guindon
Teach it to others and you will realize if there are gaps in your knowledge or if you truly understand a topic or not.
“What I cannot create, I don’t understand”
— Richard Feynman
Lesson 5: Optimise your Way of Learning
Nowadays, most engineers tend to consume certain content to educate or train themselves. There’s plenty of range, tutorials, and video courses available to supplement your knowledge.
However, you cannot rely on such material for a long time. Since such content is mostly geared towards beginners or at max intermediates, so spending time with it doesn’t make any sense since it doesn’t get you far.
This can also lead to “Tutorial Purgatory”
Sure it helps you get started but it’s not supposed to be the only way you stick around to learn. You need to optimize you’re learning to the next level.
One of the great ways of learning is sharing your knowledge as I’ve mentioned before, putting it into writing, making a video on it, teaching it to someone else, and generally sharing your knowledge with other people.
Learn by doing
One of the ultimate ways of learning that I prefer is learning by doing.
Just like a kid breaks apart a toy and puts it back into place and learns a great deal of knowledge about how that toy works,
Maybe pick a framework or library of your choice and try to re-implement it from scratch just to learn how it works,
I once implemented the virtual dom, renderer, and setState method to build my own ReactJS from scratch, just to figure out how it works,
I later compared it to the actual code of ReactJS and learned a ton of solid concepts and knowledge!
I don’t think there’s any tutorial or course that can teach you that effectively about a topic since such tutorials or courses are targeted to a mass number of users due to the monetary nature of it,
On the other hand, side, learn by doing approach is specific and individualized to you only and it’s purely driven by your curiosity.
“Know how to solve every problem, that has been solved.”
— Richard Feynman
Lesson 6: Communicate Effectively
I can’t emphasize this much!
Communication is the key when it comes to problem-solving, understanding a requirement, and overall effective team collaboration.
Ineffective communication can bring the whole team down, and I’ve seen projects and teams failing because of a lack of good communication.
Communication is a soft skill that is as important as hard skills(technical skills and knowledge) for an engineer. I’ve seen mediocre engineers with good communication skills go above and beyond the good engineers with not-so-good communication skills.
Lesson 7: Naming is important
Naming is crucial when it comes to large-scale projects, it simply reduces the cognitive load to work with the codebase. Meaningful names for variables, functions, services, API endpoints, database attributes, tables, and databases can help immensely improve the developer experience.
A name has two distinct goals:
- It needs to be clear: you need to know what the name refers to.
- It needs to be precise: you need to know what it does not refer to.
(in reference to Long Names Are Long — journal.stuffwithstuff.com)
I’ve experienced that codebases with good naming conventions were a lot easier to work with and scale,
while codebases with confusing and inconsistent naming conventions were way more difficult to work with.
Lesson 8: Testing Effectively
Testing should not just be left at the hands of QA engineers to deal with, as an engineer I should be able to provide guarantee and coverage of the code that I’ve written.
I hate to admit but I haven’t written many automated tests as much as I prefer to do so.
As an engineer, I should not only understand but also be able to set up automated functional, load/performance, and UI tests
Lesson 9: Master your craft
Understand and master the tools/technologies you’re working with inside out, and really become a wizard with it!
Keep a close eye on what’s up next in the ecosystem and how it would affect my product, project, or team I’m working with. Become a master of reading documentation and extracting information from it.
For example, if you’re using React Native for developing a mobile app, you should keep a keen eye on the overall philosophy of the framework, its advancement over time, and upcoming changes in its ecosystem.
You should be able to skim through the release notes and determine if there’s anything that I should watch out for or head up for to improve your project.
Lesson 10: Take Care of yourself
Don’t ever compromise your physical and mental well-being, if you’re not taking care of yourself, what are you even working for?
Make sure your nutrition is good, you train yourself, keep a consistent and healthy routine, and remember your attention is a finite resource, and burnout is real, so always take a break whenever you need to.
There is so much more that I could mention in that list!
However, for the sake of this post, I’m concluding my thoughts here.
I hope you can take away from my learnings and experience.
If you’re a software engineer or developer,
I would love to know what were your journey and experience like.
What are the key lessons and takeaways you have to share?
Cheers!
