Having trained thousands of people, I’ve read hundreds of online complaints from remote hobbyists who live far away and “can’t attend”.

I’m always baffled by kids who only imagine a training in Google (or another large corp) with a personal mentor on-site, a well-defined training program tailored to their taste, a team of other hobbyists at their level (or even lower) to pace together.

Companies don’t dream to invest five or six figures in complete newbies over the course of a year before some of them can become productive.

Back in the day, we were downloading .TXT tutorials on floppy disks, printing “hard to find” books due to our limited online access, and spending weeks banging our heads against the help pages of DOS-driven IDEs.

And now, we have YouTube, Udemy, tons of blogs and free books, Stack Overflow, GitHub… Most of the engineers I’ve worked with are self-taught. It’s all about motivation and hustle. Not limited to engineering, either.

Highlights

00:00:16 – Why Some People Complain About Onsite Learning
00:01:29 – Communication and Collaboration = Teamwork
00:01:58 – Finding Resources Then and Now
00:05:42 – Different Online Resources
00:06:22 – The Most Important Thing
00:07:16 – What You Really Need to Do

TRANSCRIPT

Can you become a successful web developer if you don’t get a chance to become a part of a team and work in an office with other developers on site and basically be a member of an existing kind of organization and make a team – team of software engineers?

Why Some People Complain About On-Site Learning

This is a question I get quite a lot and as a trainer, I also tend to teach some courses that tend to record training videos online and also organize some workshops and lab exercises and others onsite in order to help people to bond together and work alike instead of just learning the curriculum from the Internet. And of course, some people complain about it.

They say, “I live very far away. I can’t really attend all the exercises.” So, they kind of start ranting against being unable to be a part of the team and how unfair it is and things like that. Now apparently, this is a poor excuse if you’re about to start becoming a professional in that specific industry and in any industry for that matter, now I completely understand that most of the software engineering happens as a part of a team, as a part of a collaborative environment.

Communication and Collaboration Equals Teamwork

This is a why communication is also important. This why we stress so much on teamwork and collaboration and version control and some other activities simply because they are part of something bigger of the collaborative effort that goes into building a complex software product or delivering services or anything that’s kind of related to software engineering.

And now, I want to really stress out the importance of teamwork whenever that’s possible. And, probably, you are going to become a part of a software engineering team sooner or later even if, let’s say, you live in a city where your location doesn’t really allow you to work in a team, you can’t travel 200 miles every single day just to commute to your job or anything else. But, that doesn’t really mean that you can’t learn software engineering on yourself.

And, the reason I want to mention that is that back in the day, we simply didn’t have the opportunities to study software engineering by going to boot camps or going to some training courses or things like that. And again, I also know people who have started develop and 20 years before I did and this was really a lot of irony. Really a lot of trying to figure things out in themselves, simply because no university were teaching this or there were pretty much no opportunities for training on site.

To Be a Successful Web Developer Back in the Day

Back when I started which was about 20 years ago, give or take. When I started, we were trying to look for any type of all our websites, just giving any types of tips on be it software engineering or web development operating systems networks and so on.

And, the internet wasn’t that popular back then either so most of the time, we spent the time in computer records and the internet cafes and some other places trying to find some of those websites and then bringing floppy disks. And, trying to download these as HTML dog files or even sometimes, take stuff out if they were large enough so they couldn’t fit into a floppy disk or two.

So we just had to take this information one way or another. There was no stack overflow or I don’t know, any types of groups and online courses. Basically, video online wasn’t really a thing because the Internet was 56 cubit per second modems which were taken about 25 minutes to download an mp3 file. Right? So again, we are talking about a where this information was probably one-thousandth of what is currently available online. Yet we were able to find it one way or another from some places and also spending a lot of time on actually trying to build software ourselves at home until late at night and reading some complex computer science books and everything else that we found.

On Finding Resources Then and Now

I remember, again, that was around this period about nearly 20 years ago I remembered and found the C++ book by the Bjarne Stroustrup and we found someone who had a copy and this wasn’t something that was sold locally.

So, we basically had to go to a Xerox and make manual copies for each of us which was something like this even though the book was this fat. I know this is not the best solution whatsoever, but again information was very scarce. It was very hard to find it. And that’s why we had to find some collaborative efforts to make it work.

Also, when we were studying say, two basic course of Delphi, we were reading 100% of the documentation and trying to work out every single function, every single command, every single procedure, everything that was available in the help, was there for us to help and we didn’t really have enough resources to help out otherwise.

So, what I’m trying to say is back in the day, it was ten dozens, probably hundreds of five more complicated to actually study software engineering. And what people have nowadays is the ability to just, I don’t know, travel to work and be able to play YouTube videos or Udemy videos or something else on their phones and even being able to actually program on their phones because phones are that powerful right now.

The one I’m recording with has a chorus and 8 gigabytes of RAM. It’s like more powerful than my previous laptop. So, and still that sort of ability, that sort of capability is something that you really need to recognize. Same goes for the types of software engineering platforms and frameworks and programming languages and everything else that you can pick from.

Different Online Resources

Because even if you have scarce resources on one thing, you can probably find Java resources for programming for the Android platform. You have Google pretty much presenting you complete tutorials from start to finish for a usable application. Again, you have Stack Overflow. You have GitHub and GitHub is completely powerful repository tens of millions of applications that you can download and run and read their code and also read through Commits and backlog conversion, pretty much everything that we didn’t have a long time ago.

So, there’s literally no excuse to not start working yourself and start developing your skills from scratch.

One of the Biggest Misconceptions

Now, the most important thing is that most people struggling with learning upon themselves. What they tried to do is they start with the syntax and expect that when they learn the dozens of keywords and just be able to say, create a function, create a class, they’re pretty much ready to go. And now that’s one of the biggest misconceptions that I found in software engineering simply because it’s like knowing the letters of an alphabet and expecting to have a fluent conversation with legal teams in the counting case.

I speak fairly well English and they really can’t find myself in decent gourmet restaurants simply because I have no idea what all of those ingredients are. I can’t pronounce them and I don’t know what they look like. And how about, for example, if you don’t know Arabic or Russian or something like that, just adding the alphabet and then be able to just have fluent conversations, right? It doesn’t make sense at all.

What You Really Need to Do

So that’s why just learning the syntax of a programming language pretty much means nothing. What you really need to do is start solving business problems. That’s the most important thing. Now, computer programming in the first place is designed to solve problems that humans face on a day to day by ultimatum then by sifting through the inserting records maintaining archives things like that. So what you again need to do is realize what does an actual business case require, how to build a corresponding application that solves all those business cases.

For instance, if you have, one of the standard cases that most kinds of courses study and teach is actually a library application. So you need to consider what does a library look like, what would a librarian need to do, how would books be received. And then, design the corresponding say, database layer, a software desktop application that sits there, probably an online archive like a book collection, everything like this and just start small, start with one piece, start with the book component, book object, book class, and expand from there.

Start Solving More Problems

Once you learn this, once you actually build a couple of useful applications, it would be much easier for you to apply the corresponding design patterns. Start solving more and more and more business problems through programming instead of just focusing on the syntax or instead of just expecting someone at work to mentor you, and coach you and train you. And, actually spend all their time as a software engineer, probably, with a senior who’s teaching you, who’s actually on the payroll and who’s actually being paid to work on an actual application.

So again, teamwork is important. Communication is important. Collaboration is important, but that doesn’t mean by any means that you can do this, all that yourself, because you have tons of different resources, you have the internet, you have free materials, you have cheap online courses, and you can take it and start building some applications from yourself.

Build several applications with tutorials then start to build some pet project of your own and take it from there. Sure, it’s going to take a lot of time. It’s probably going to be annoying, but this is one of the best ways to start debugging and kind of stumbling and form problems, trying to understand them, solve them, and take it to the next level with your newly acquired knowledge about this.

It’s a slippery slope, especially with small agencies giving away titles due to their smaller scale.

Niels Bohr once said that, “An expert is a man who has made all of the possible mistakes that could be made in a very narrow field”. And this sums up seniority in most areas out there.

– The senior developer can solve almost every technical problem with little to no supervision.
– Junior developers, on the other hand, can only solve limited types of problems with a small subset of alternative solutions.

Disclosing a few essential nuggets in my latest video here. 🎥

What’s your take on juniors vs. seniors in your industry?

Highlights

00:00:07 – What is an expert?
00:02:14 – Senior vs Junior developers in practice
00:04:24 – How to define a career in software engineering
00:05:42 – Going through the learning curve
00:07:57 – What is really crucial even for seniors

TRANSCRIPT

What is the actual difference between a junior software developer and a senior software developer?

I get this question frequently from juniors who really want to figure out how to become a senior or how long does it take to become a senior, or what is the actual path to becoming a senior developer. What’s the quickest way to become a senior developer and whatnot. And, to be fully honest, different organizations are just handing titles for whatever reasons especially smaller teams and smaller agencies especially less progressive companies where you can become a senior in just a matter of a year with the right attitude, just kind of standing out from the rest of the audience. This isn’t really the case for larger organizations where they do have a pretty well-predefined company hierarchy but it’s definitely the case in a smaller company.

What is an Expert?

So, Niels Bohr once said that, “An expert is a man who has made all of the possible mistakes that could be made in a very narrow field” – meaning that, experts are really people and I’ve already talked about experts and how flaky this word is so don’t quote me on that. But, seniors and experienced people are the folks who have already gone through all the use cases in a very narrow field. They’ve made all the mistakes. They know what are the implications, what are the problems, what are the best practices and what will happen when you make mistakes.

And, as you can imagine, this means that to become an expert you have to go through the path that leads you to all those mistakes and as tricky as it may sound, it really means that you simply have to fail – fail often, fail a lot, without of course compromising prediction software. But once you go through all that part you can learn from your own mistakes and really figure out what are the best practices and the best ways to make it work.

Ideally, you aren’t going to go through this path before you even start a job by working on pet projects, by reading lots of programming books and going to, reading, listening to podcasts and going to events and just trying to reduce the number of failures when you still need to go to all those different use cases – meaning that, you need to work on a large set of projects within an organization, understand the different issues, and a bunch of other things.

Senior vs Junior Developers in Practice

So, a difference in a practice or how to compare, kind of a junior or a senior, is a senior developer can solve almost every technical problem with little to no supervision and all that all is going to be well documented well tested with inline comments and everything else. So you can easily assign a complex task, a small project to even a mid-sized project to a senior developer and you are going to expect that they will comply with it. They’re going to follow the regulations. If there is a problem, they are going to indicate it early on or commented well, documented and everything else.

Junior developers on the other hand, can only solve limited types of problems with a small subset of alternative solutions – meaning that, if you give them a pattern and if you give them a framework and say, you need to replicate it 10 times, it is definitely doable. If it’s simple, if it doesn’t require too many dependencies – these are usually a junior developer’s job.

When the Devs Approach a Task

So, think about, you give, let’s say, rebuild WordPress or build a blogging tool and you give that to a junior developer on one hand and the senior developer. So, the junior developers are probably to say, if they know what programming language, what framework, they are going to say, “Yeah, I know Java so I’m going to build it with JSF or its print framework or something else. I’m going to make it work and you know is going to use Oracle because that’s what I use and he’s going to have different roles and yada yada.” But then the senior software developers are going to say, “Wait, first, why do we need to do blogging tool? We already have plenty of those. It doesn’t make a lot of sense. To make a decent blogging tool, you have to invest a lot of time, resources, QA. It’s expensive.”

So, they’re going to really look for a rationale if it really makes sense, if it’s proprietary, if it’s limited, they’re going to say, “OK, you know if it handles tons of different unstructured data, we are going to use a noSQL database like MongoDB whatever. Then, we’re going to do a set of simplified layers if it connects to other javascript applications. We may as well be with Node.JS or it’s going to do it with static pages or a bunch of other different things. Right? So, you can definitely kind of wiggle through the choices and figure out what is best for the business.

How to Define a Career in Software Engineering

And with that in mind, really, the career in software engineering is defined by the depth of knowledge and the breadth of experience. So we have the depth of knowledge – you really need to understand a lot about a different field and then you have the breadth of experience in dealing with different types of problems with your knowledge and just to plan your knowledge stack into different sorts of use cases. So, that’s pretty much how it goes in a nutshell.

Junior developers, again, they are usually familiar with lower subset of paradigms, use cases problems and they don’t yet know how to apply new paradigms here. And, most of them, if they have a problem, they’re going to get stuck, or they’re going to ask a senior or they’re going to read something on forums which is not necessarily quite helpful.

Simply, pretty much you have to go through all that experience yourself and just get comfortable understanding what are the pros and cons of different tools, paradigms, design patterns, solutions, strategies, frameworks, and be able to analyze and understand what are the implications of using each and every one of those in different use cases because there is no right tool for every job. There are different tools for a reason. They serve different purposes for different audiences for different types of programs.

How to Determine Seniority

Sometimes, a performance may be an indicator. Traffic could be user base, could be a bunch of other things or security, adaptiveness, number of people available in the organization who can build something other available tools online. What are the pros, what are the cons, what are the business implications of a specific case? And senior developers seem to have lots of experience to be able to comfortably make those assumptions and make actual strategic consulting in order to, again, make the right decision at the end of the day. So, that’s more or less, the difference between junior and senior developers.

One other note that I’d like to make is that sometimes, senior developers in an organization could be less experienced programmers who have spent plenty of time within the organization because seniority in software engineering for the most part, in most companies, isn’t related to the programmings skills you’ve got – programming knowledge, clean code, faster execution refactoring, fewer regressions, no technical debt and things like this.

Going Through the Learning Curve

But, in some organizations, there is the learning curve when you develop. Or,  meaning that, if the learning curve is really steep, then new developers or even senior developers may start as mid-levels because they can’t grasp the knowledge of a business and the business implications, the business context, the business structure, the business model, may be very unique to a certain extent, leading to making it hard for a new person to join in and at the same time, or, on the opposing again, you also have less experienced people who may be acclaimed as seniors simply because they may not be as strong on the technical standpoint but they may take the right and make the right decisions depending on context.

They may say, “well I only know, (just as a very rough example), I only know two or three technologies, or two or three frameworks, whatever it is, but I know that in this case, we need to do this because it’s a very complicated case. We’ve already worked with those plants three times over the past five years. We know that they are very specific here. This is going to help us do this. This is going to improve our efficiency here. We already have internal systems that do this and whatnot.”

What Is Really Crucial Even for Seniors

This is also the reason why CTOs are not necessarily the best developers in the company. And quite the opposite actually in plenty of companies, CTOs are probably, kind of mid-level skillset or so technically. Or, at least above average. But, they simply have the ability to represent the entire information technology infrastructure, how it tailors to the clients, what the clients need, business requirements, business expectations, being able to pick the right solution depending on timeframes and budget and resources and other things that senior software engineers also have to understand for the most part. The more they understand them, the more possible for them to step up the ladder even further

So that’s about software engineers. Again, there are different concepts and different ways to represent each one of them and companies may vary. They have different layers and different forms of assessments. But, if you’re a junior engineer who wants to really become more senior, practice makes perfect. And also, understanding business requirements, understanding how important is to produce clean code, learning – continuous learning – is really crucial even for seniors and just becoming better and better with every single complete project.