#1 Tip On Becoming A Better Software Engineer

Beginner software engineers are clueless at work — even with the best mentor on the job. They lack the overview of the bigger picture, corresponding technical layers, operating as a part of a team, utilizing internal tools and a lot more to that.

It may get depressing and troubling, especially in more agile teams and startups.

My key technique is reverse-engineering business and tech requirements.

🎯 Break down the project goals into layers and components.
🎯 Analyze and simplify each one of them.
🎯 Quantify and assign to milestones.

After all, we use reverse-engineering in our lives at any point in time.

📈 School? Investment in a better education or a future.
📈 Career? A step toward a safe workplace unlocking a better lifestyle.
📈 Family? Fulfilling your emotional dreams.

But that’s just my 2 cents. What’s the technique that worked for you?

Better Software Engineer


00:00:20 – The difference between a junior and senior developer
00:01:14 – My no. 1 tip and how developers work with it
00:03:06 – An analogy between engineers and managers
00:04:09 – Here’s the shortcut that I’m suggesting
00:04:21 – Problem 1: Jumping the gun too soon
00:05:18 – Problem 1: Thinking way too much
00:06:10 – Recap: Understanding the bigger picture


So, here’s my top trick (tip) for junior developers and entry level developers who want to become better at building software applications. I saw a question on Quora that says, “What’s Your Number 1 trick or tip for becoming a better software engineer?” Assuming that this was someone who is entry level, still at university, at their first job or something, and they want to become a better software engineer, which is something admirable, something that I’m really striving to help people with.

The Difference Between a Junior and Senior Developer

So, when trying to answer this question, I was trying to counter question myself with the following. Now, what is the difference between a junior developer and a senior developer and an experienced software engineer out there? So, when thinking about this question, the few answers that came to the top of mind are, experience, the ability to solve complex problems, the ability to predict different types of problems that would come up, experience, context and the ability to see the bigger picture. So, if I tried to take apart some of those, to break them apart into modular pieces, then I have to synthesize that and build them into something more comprehensive and more sane, more or less.

My No. 1 Tip and How Developers Work with It

Now, I would say my number one tip would be building or rather reverse engineering the final platform you’re about to offer. Most people tried to do this. Most junior developers that I’ve worked with, they’re pretty hesitant, they’re fairly chaotic in building software applications because they lack the experience. They don’t know how to start, they don’t know what are the best practices and they simply lack the experience to build a software application.

So, they need to take the more structured route in order to stay sane in the profession because otherwise, they would be fairly clueless, really unaware of what’s the best way to do whatever they’re supposed to do at work. So, in order to do that, they need a level of organization, they need the ability to create some form of a framework which they should follow onwards. So that’s kind of one of the best tips that juniors should follow.

Reverse Engineering as a Project Manager

As an example, rather the best way to do that is through reverse engineering approach which helps people kind of figure out the final solution and then reverse-engineer to the components and kind of elements and modules and everything else they need to build. That’s essentially how project management works too and especially the Waterfall Model.

With Waterfall, you have a client they come with a list of requirements, they need a budget, an estimate, and timeframe. So what managers usually do is they try to ask all the right questions, gather all the required context and then speak with the Dev team in order to get the complete features set in order to complete the project. So of course, it only makes sense, that’s a standard scenario, and the developer should follow a similar approach.

An Analogy Between Engineers and Managers

Now it’s also important to make an analogy, to make, kind of, a parallel between junior and senior level engineers and project managers. Why do I say that? Because with the very same scenario with a project that needs to be estimated, a junior project manager won’t be able to ask all the right questions and that’s completely okay. So, there would be some mistakes here and there. You know you would fail once, twice, three times but every single time you’re going to get better.

You’re going to learn to understand the context. You’re going to learn to build a scenario to build the kind of the least of all used cases that you need to consider and ask your client in order to assess what they actually need. So, what is the most optimal way to build so that they have all the features but at the same time, you know, you don’t budget them with something completely insane given the fact that they want to use 90 percent of the features that you’ve planned to build.

So again, that’s the same parallel between juniors and seniors both in the software engineering field and the project management field too.

Here’s the Shortcut That I’m Suggesting

But the bottom line, the kind of the shortcut that I’m suggesting is just thinking about the reverse engineering of an application. I’ve seen and I’ve been preaching that for a while and I have some people who do one of two things and still fail.

Problem 1 and 2 When Reverse Engineering

Number one is trying to imagine the complete scenario, the complete list of features but jumping the gun too soon and trying to solve those problems without really any sort of sequencing, any type of a project plan. What I’m saying is, you know, someone says I want to clone Facebook, and I say okay, well Facebook has posts, groups, and users. So, let’s just start to build with some users and try to interact with them then let us build some simple dumb posts, then try to work in some groups and take it from there.

So, this is lack of organization like we said a bit earlier, the lack of structure, the lack of organization isn’t really helping beginner developers to take their life into their own hands and build something meaningful and reasonable without having to rebuild that. That’s kind of problem number one.

Problem number two is taking a separate approach like trying to think way too much of what a product needs from the start to the end and not the other way around. If someone wants me to build Facebook, they say, “well I need to be able to do posts, also I’ll need users, also I need groups and I also need video messages and feeds and this and that, this and that”, it gets pretty messed up. You can’t understand all the used cases as to how does everything relate to one another.

So, it gets a lot more confusing and there are way too many different outcomes while if you have a single outcome of the end, it’s easier to reverse engineer it and just try to extract every single module and then plan it as a separate kind of library, as a separate subproject or framework or whatever it is.

Understanding the Bigger Picture

So again, if there is a single, just one trick I can give software engineers especially beginner ones, it’s trying to understand the context in the bigger picture and reverse engineer it in your own kind of subproject management system or given your own time frames and so on. So again, if someone comes and says “well I want Instagram, working on Instagram (I’m only using familiar applications for a reason)”, so if you do that you need to have an action plan on how to build on Instagram over time.

With that in mind, you need to take Instagram as a final platform and you need to break it apart into the different pieces that Instagram has like just the ability to upload a photo, filters, the feed, users, connections and everything else. Everything else from that specifically, so you need to categorize it, classify it and see how are modules connected to one another, which is exactly the context and what is the best way to make it work. Then when you ask the follow-up questions before proceeding further, it’s very likely that some of those questions would be based on your initial due diligence for what does Instagram represents and what does it look like and how does it work behind the surface.

Assessing the Need for Some Constraints

So, with that in mind, you probably need to assess the need for some constraints and by constraints, I mean if you’re building that software what’s the content base that you need to support. Like how many posts should your initial build support, should these be 500; 5,000; 50,000; 500,000; 5,000,000; 50,000,000 and so on. Because this will determine also the software architecture, server level, hyper availability, different high availability and different types of architectures for building the right toolset.

So, this again will also come into play once you have the bigger picture. So yeah, the very same thing goes regardless of the solution, just get the solution try to reverse engineer it, try to break it down into different phases, trying to build kind of an action plan as to how would you approach that and then once you have that just move forward and start building your minimal viable product.

Most of the time it works really well because you understand the end goal, you understand the bigger picture, it’s easier to assess where are you now and what does the end goal look like. It’s also easier to build upon a solid foundation without having to always keep refactoring and cleaning technical debt and it’s less demotivating if you’re just building stuff for the sake of building without actually having different milestones to hit.


So yeah that’s pretty much it. Try to understand context, understand business problems at hand because it’s really important, it helps you make the right decisions, understand the bigger picture, reverse engineer it, build it into a kind of different milestones and then, take it from there. This has helped millions of young software engineers. Give it a shot. This may or may not work for you but it’s definitely worth trying.