- Hey Tech lead here, and welcome back to another episode. Today we are going to talk about the top signs of an
inexperienced programmer. It is coffee time we
are having a Coca-Cola. A lot of people like to hate on Coca-Cola, but it's not so bad. Nothing wrong with that. This video is sponsored by Coca-Cola. For fun times have a Coca-Cola. Is what I would not say. Because I am not sponsored by Coca-Cola. This video by the way is sponsored by audibletrial.com/techlead. Check 'em out for your free audio book. I use it all the time. I've been listening to
audiobooks on my commute. Saving a lot of time. Currently I'm listening to Zero To One by Peter Thiel. That's a great book. Lots of lessons from experienced people. They've got tons of audio books available whatever you're interested in reading. Remember that Audible is actually owned by Amazon. So their selection is massive. Check 'em out, get your free audio book. audibletrial.com/techlead. You know it's a funny thing that all new engineers
exhibit certain traits. And just by looking at the way they act. The patterns that they go about in their daily routines. The code that they output. You can pretty much tell who's an experienced
engineer and who's new. And these new engineers all go through the same things. And it takes them sometimes months, sometimes years to
outgrow their behaviors. To turn pro, so to speak. Every new engineer has to go through this training in every single company, and it's just tiresome. The same lessons need to be repeated over and over again. I thought I would just give you guys the basic tips such that
when you get started, or if you're already working, then you're going to be well on your way, and people aren't going to have to give to you the same lessons over and over again. You know, it's funny that when you start working at say, a company like Google, they like to haze you in
your first code reviews. They will leave you hundreds, if not millions of comments in your first diff output that you're trying to commit. And people will just say. Hey, this is wrong, this
line of code is wrong. This line of code is bad. There would be so many pedantic comments that many people just end up quitting the next day. And that's the funny thing a lot of people don't know is that. Half of the people who get into say, Google as an engineer. 'Bout half quit before they even submit their first line of code. So let's get into it. The first tip. And this has been repeated
over and over again. Is keep your div sizes small. Keep your comments small. Chances are when you first start, you're going to be
assigned a starter project. That's going to require a sizable chunk of code to complete some feature. And the key to note here is this isn't so much about completing the features. Probably a useless feature that nobody even cares about. What people really wanna see you do is start learning the coding practices. The development process in which you get a code submitted. And this really involves their process in which you break down the project into bite sized chunks. And you submit targeted
small pieces of code one at a time. Instead of submitting the whole thing. And chances are when you submit this whole piece of
code for a code review. And it's thousands of lines of code, people are just going to look at it and say: "Hey, yeah, this one line here, this one way that you did. This was entirely wrong
and the whole thing needs to be redone." When you get started,
there's a high chance you're going to fundamentally
get some patterns, some design or architecture of your program wrong. It's going to change the whole way that the things going to be written. So if you submit small
sized divs incrementally, people can help make sure that you're on the right track. You're not wasting too much time. And it also makes it
easier to lend your divs because it's simply easier to get approval on small sized chunks of
code are very targeted. Instead of a whole
menagerie of random divs. Many times I will actually write my code in an editor that shows line by line divs of what changes I'm making like Visual Studio code, or
Adam will show this. And this helps ensure that you're not just changing
random lines of text that don't need to be changed. Almost every company I go to, they beat this one lesson about having smart divs over and over to new engineers. If you go into the company
already knowing this, you're going to be set. Now the second sign of a new inexperienced developer is just crazy tangled codes. Crazy logic all over the place. Huge functions. Tons of if statements all over the place. Random helper methods everywhere. Premature optimization. Over engineered garbage code. And so contrary to what you might imagine, bad code is not simply code that has a ton of bugs. Doesn't compile, doesn't work. A decent engineer will at least be able to get their code to compile, to work. And is even going to
run and function okay. But the way the logic is set up. The way the code is written is going to look completely horrible. It's gonna look like garbage code. Tangled, totally messy, complex stuff. And it's pretty much going to be a complete pain to read. Many times, I would just get a headache after reading some beginners code. And then I have to get up
and get a coffee break. My recommendation here
is to write a design doc. Write a document that describes what you're going to build. What the feature requirements are. How you're going to set things up. Which functions you're going to need. Which classes, what data structures you might need. And then just go build those out. And that should help
you organize your ideas. It's very obvious. Actually, when I see code that was written without design doc. Because there's just repeated duplicate code logic. If statements all over the place. It somehow manages to work. I mean, the codes going to work fine. But it's just going to look like pretty crazy code. I'm probably going to go ahead and approve your code anyway. But I know it's going to cause you a lot of hell later on. As you're going to become the one maintaining this code
throughout your career. And it's just going to slow you down through the rest of your job over the months, as you're going to have to start adding
features to this code. You're going to have to start reading it. And there's just going
to be bugs introduced. Every single time you
tried to modify the code, you're going to have to make changes in a whole bunch of different areas. The logic's going to be pretty loopy. Write a design doc,
save yourself some time. It's gonna make you look
a little bit better too. The third trait of a new
inexperienced developer is low effectiveness. Now, don't get me wrong,
everyone's working hard. Everyone's trying to prove themselves. They know they're new, they're trying to do things. But they're just not effective. And they end up wasting tons of time. I know a guy who was
working on this feature for months, and it was
a pretty complicated UI. In fact, the UI was
essentially impossible to do. You know, the UI designers
just came up with it. And he started to trying to work on it and coming up with
totally convoluted code. None of it was really done well. It was very hacky stuff. And I think he just wasn't having his eye on the goal. He was just obsessed with maybe doing a bunch of groundwork. This project never launched, by the way. And later on, I came up with a better solution for it. I pushed back on the UI designers loop and said: "Hey, if we do it this way, it's going to be much easier to implement. It's going to look good, too." And so I would say don't just code for coding sake. Look at the forest, not the trees. Keep your eye on the vision, the goal that you're trying to make happen. And make sure that your
code at least ships. And if you don't foresee
your code shipping. Tried to clear the roadblocks for that. Make sure that you can get your impact in where you can. You also want to keep an eye on your APM. Actions per minute. I know a lot of engineers they go in and they spend the whole
day surfing Reddit, checking Facebook, social
media, blogs, Twitter. Surfing news and. I look at these new engineers screen. Half the time they're watching a YouTube video of someone playing a game. Maybe they're the one playing the game. Maybe they're even broadcasting that game. And that's all great. People can work like that. They can work on their
own time if they like. And I used to sort of do this too. I was going to work and
I would have one window. Maybe I'll do some online shopping, whatever it is I want to do. But the thing is when you play a game like Starcraft, you know there's that whoever has the highest APM usually wins the match
in the Starcraft game. Not always, but usually. It really goes a long way. So that's really the same thing for developers as well. If you're spending any available time you have on the job, for instance. Just imagine how much more productive you might be able to be. You know, you could get probably a lot more code submitted. Read a lot of code, learn
about the code base. Come up with ideas. You could get a whole bunch done. And I would say that one
flaw of new engineers is sometimes I'll take a look at their code output after a whole week. And they may have submitted like one or two pieces of code that whole week. And just sort of wonder,
how is it possible that somebody could spend five days at a job and submit
only two pieces of code? Or even one piece of code or none? In the whole week? And then I remember
oh, yeah, that's right. They were probably playing
games that whole time. Maybe they were doing
online shopping, who knows? And it's kind of no wonder that for a lot of these people. Their productivity is just very low. My recommendation is try to get at least one piece of code submitted per day. That'll keep you on track. Make that just a personal
goal for yourself. That'll keep you going. The fourth sign of an
inexperienced engineer is they usually have a lot of pride, a lot of ego, a lot of arrogance. And this is something that you see out of a lot of computer science students coming out of college, for instance. Their arrogance is just incredible. The worst is when I'm reviewing a new engineers code. And I decide to leave
like, say, 100 comments. And then the engineer comes by my desk and personally asks me about each comment and tries to justify why he's right about each one. And then have to get
into a little argument about each one with him. And he's trying to defend himself and laughing at other people who may be more stupid than him. Trying to sound cool,
trying to sound smart. It's like, look, I don't care if you think you're cool. I don't care if you think
I think you're cool. If you want me to say you're cool, fine. You're cool. I'm cool. We're all cool. Everybody's cool. I'm just cooler than you, okay. So the thing about arrogance is it has a lot of other effects as well. For example, it causes engineers to over engineer their code to make it look really smart and clever. Keep it simple. Also, I would recommend that you swallow your pride and go ask for questions. Ask for help when you need it. It can save you a ton of time. This kind of goes back
to being ineffective. A lot of new engineers
just wanna to tackle everything on their own. They spend a lot of time doing things on their own. A week or two later, they surface again with a bunch of garbage code that they've written. Then I have to say this
whole thing was wrong. This whole thing was just no good. That I wish they would've just asked an experienced developer. Like myself. But I would have approved
and that could have saved everyone a lot of time. My last and final tip. The sign of an inexperienced engineer. Is somebody who does not identify and respect that tech lead. That's me. Make sure that you know
who the tech lead is. I'm not talking about your manager. I'm not talking about your boss. You may already have a
tech lead at your company. That may not be the tech lead. That person could be x
Microsoft, for example. I am x Google, Okay. x Google tech lead. You want to make sure you know who the tech lead is. And I have a story for you. One time there was this engineer. He did not respect the tech lead He dared not to. And let me just tell
you what happened to him because this is going to be a good lesson for all of you. He said they're proposing
tons of random code for his project. No design doc. Huge divs, very complicated logic. And I pushed back on it and said: "Yeah, this
isn't going to work." He did not respect my
comments and kept pushing forward with his code. He kept proposing tons of code. Disappeared, came back two weeks later with a bunch more additional code. Didn't listen to a single comment that I suggested for him. And I blocked every
single code that he tried to put in. That's right, I would block his code. I would just spend all my time writing millions of comments. And he would have to write millions of replies back. Eventually we started just writing essays on these divs. We stopped coding really. His effectiveness, his code output got dropped to 0. You know what happened to him? He got fired. That's right. So, that's one lesson for you if you don't respect the tech lead. I would recommend if I were you to actually be nice to the tech lead. Do whatever you can for him, you know. Bring him lunch, bring him tea. One little trick you can do is instead of you submit code, come up with a div patch. Mail it to the tech lead. And then the tech lead will patch your div and then submit that for you. And that way the tech lead will get credit for the divs. It just helps increase the number of divs that the tech lead is putting out. What you can also do is when you write design documents. Put the tech leads name on it. Even if I had no part in the design doc or presentation, or
email, or post or whatever it is that you're writing. Just put my name there in the authors. The credits line. That would be great. I would appreciate that. That helps me get a
little bit more credit. A little bit more awareness for people like me. Who are here to take credit for your work. But me stuff, give me things. Give me money. Any of that, I'll take it. Respect the tech lead. That will do it from me. Feel free to share your top signs of junior engineers in the comments below. If you liked the video, give it a like and subscribe, and I'll see you next time. Bye.
Can't believe no one's mentioned this yet on this thread but higher APM does not = usually winning the game. Ofc, if your apm is vastly above your opponent's you'll have a big advantage, but I don't think we've ever had a statistic that the higher apm pro usually wins in SC2 matches. Then ofc, there's EAPM vs APM comparison, etc.