17
May

5 must have skills to become a programmer (that you didn't know)



oh yeah that's a good stuff hey tech wait here and welcome back to another episode ah that's good at this rate I'm drinking about three cups of instant coffee every day and you may be thinking well that's pretty unhealthy but it's not actually because if you check the ingredients it's just coffee instant coffees so you know I can just drink a bunch of this a better question you may be wondering is at this rate maybe I should just be investing in a normal coffee machine given that I'm drinking so much coffee every day and you might be right but at the same time it just takes a lot more work to be making coffee doesn't it well I thought I would go over for you guys today our five must know skills for software engineers and this may be especially useful for universities students people who are just getting into tech trying to become programmers and people who aren't necessarily aware of other skills that may be required or needed for the field you know we all know the obvious ones right like you need to know how to program you need to learn a language and maybe you need some communication skills do some problem-solving whiteboarding algorithms data structures is that it and it might be actually for you to pass a certain interview or something but over time and it may even help you look better if you were to learn five additional skills and these are skills that in my opinion every single software engineer should know they're not necessarily obvious but over time you realize that every single software engineer took the time to learn these things the first one is regular expressions surprisingly I find that a lot of university students they're not really knowledgeable about regular expressions unlike me I'm like a pro at regular expressions I use them all the time I've built entire databases out of regular expressions when I didn't want to use a standard like sequel database and regular expressions can accomplish so much it's a way to do pattern matching on text the most obvious usage is for searching large code bases for certain pieces texts using tools like grep you know many code editors support this like sublime Visual Studio code regular expressions or rejects is are often used for searching across large code bases doing search and replaces refactoring code they can even be used as code checks to prohibit committing certain strings of text certain styles of coding using regular expressions you can scrape websites parse poor data create entire web applications where you read and data validate the user input store the data in a certain format and then read that format back you can do all of that with regular expressions you don't even need a database every single company I've worked in has depended heavily on regular expressions if you're not familiar with them I recommend you have a gallon board moving on the second skill that most developers should know is sequel a lot of developers offend especially if they're junior they don't really know sequel yet but eventually many developers wait go on to learn sequel what is equally important you know sequel is a database language is for querying database tables creating tables editing them reading them and you might be thinking to yourself well you're not a database engineer what do you need sequel for turns out data metrics are very important for any engineer in order to launch any feature you need to be able to check out the data analyze it logging is very important in order to measure the impact that you have you know you don't just ship a feature you ship the feature and then you need to say well it increased over our application usage time by two percent it dropped some other metric by one percent but I recover that in some other way and sequel is essential for being able to query your data logging metrics dashboards and be able to figure out what data is there these days in most companies in order to launch any feature you need to have the metrics the data to back that up and in order to obtain those metrics you need sequel that's why it's going to be helpful for any engineer to at least be able to write a few standard sequel queries using like group by order by aggregation things like that the third skill that we all need is debugging skill all too often I see engineers if they know how to code but they don't know how to debug and they don't pay much attention to it they just say you know the compilers wrong I don't know they can't figure out where bugs are there's just no problem-solving ability there even though they know some algorithms and debugging is really the art of problem solving being able to quickly identify where in the code a bug may be because for the majority of engineers most of your task is going to involve fixing small bugs you know there's a bug figure out where it is and then fix that bug and many times these bugs can be obscure kind of strange hard to track down the ability to debug is going to be very important here and not only that I would say but if you're working on say mobile apps for example you're going to want to be able to use the debugger gdb step through the program create breakpoints maybe even check out source control check out the versions history of a file and see where it changed at what version and where the issue may have first cropped up oftentimes people see me as a senior engineer asked me to go fix a certain problem that no one else can fix it's not necessarily because I know some algorithm better than some other person is simply because I know how to debug a program more accurately and precisely it's really about analytical and problem-solving skills my fourth tip for you and this is what separates the truly great programmers from the mediocre ones is scripting tooling being able to create tools for yourself and you know I have heard a quote recently that said all of the best programmers are writing their own tools if you're not writing your own tools to speed up your own process your own workflow you're just going to be limited but the tooling that has already provided you know I think what really makes software engineers highly productive the difference between an engineer who is outputting 1x code versus 2x code or 5x or 10x code is the tooling and usually these tools are going to be written in a language like say Python maybe PHP bash you can even use like nodejs JavaScript maybe Ruby on Rails or go Lane some tooling language that can we on the command lane and you know these scripts can be used to help expedite your overall workflow for example for Cobra factors you may be writing a script there's only a one time usage thing and it can analyze a repository of code and override detect unused files may be buggy lines of code I personally write my own script wrappers on top of version control so I'm not necessarily using like say git or mercurial for version control I'm using my own system and I find that that for me helps be that my personal workflow so I would just recommend that you're not ignore the script inside this is going to involve maybe having some familiarity with bash Linux UNIX and a language like say Python or something like that for the fifth final and last tip I could have chosen a lot of things but I think I'm gonna have to go with antisocial skills and and their social skills are very important for a developer you know if you just go to your co-worker James and you say hey James how's it going are you feeling okay buddy do you want to go grab a quick beer can I cheer you up friend how was your weekend all of that is not really providing much value for anybody and James may even decline your invitation to go out because he's a busy guy everyone's trying to be productive on company time and so the standard social skill is not really useful but you need some sort of social skill communication is still very important your antisocial skills is really about communication without being social and this may involve writing emails creating wiki pages posting to groups setting in PowerPoint presentations creating Excel sheets and notes and properly circulating them it was funny that I've worked in some companies where I might send a private message to somebody and that person would explicitly decline to communicate back with me because they would say that this private messaging does not surface the conversation for anybody else to see that type of socialization is actually frowned upon and what people really want is a way to preserve history preserve the knowledge and circulate it with as many people as possible the proper forum for that may be like a wiki or a widespread email message or something like that where many people can see the at the conversation you know this may also involve if you have a one-on-one conversation with somebody well sure yeah that's so sure but after that you want to capture that conversation in an anti-social manner in which you write down the notes of the meeting the conversations and then you circulate that across your team so that everybody knows what was discussed that so for those of you who are not social butterflies I would take some consolation in knowing that I don't think anyone's really asking you to be a social butterfly there's actually a whole other set of socialization communication skills that are needed that are required for software engineers that actually have more to do with being the antisocial but yet communicating effectively if you're looking for more tips for software engineers be sure to also check up daily coding problem comm slash tech lead for daily interview coding problems they'll send you a free coding interview question every day just to help keep your skill sharp and if you sign up as M scribe they'll also send you the solution so check them out daily coding problem comm slash tech lead so they'll do for me let me know if you guys have any tips you'd like to share in the comments below if you liked the video give it a like and subscribe and I'll see you next time bye

Tags: , , , , , , , , , ,

49 Comments

  • Busy Programmer says:

    Learn ReactJs https://youtu.be/8e3FECwCoC4

  • Aiham Alkaseer says:

    Instant coffee? Disappointed in my techlead

  • John Cat says:

    I wish I could tag this as a funny for the coffee comments! lol

  • Yasser Sinjab says:

    This guy is hilarious !

  • Steve Glover says:

    NOOOO!!! Techlead… say it isn't so… . .. instant coffee?!?

  • Dan says:

    first skill: gulping coffee with style

  • Wayne C says:

    Just passing by to say that instant coffee is yuck.

  • Mr. Infinity says:

    coffee iself is unhealthy

  • LazlowFromSpace says:

    asocial, not anti-social
    Huge difference.

  • JustmeJoy7 says:

    This was good information! I subscribed. Thanks for sharing!

  • Ingwie Phoenix says:

    I've been doing code since a bunch of years as a hobby and im planning on getting into business… Well,. time to watch this video!
    1: I suck at them. XD I can use sed and grep to search and replace for basics, but anything beyond simple strings is mind-exploding for me…
    2: SQL? Can do! But the way you pronounce it kinda made it sound like "Sequel"… But, its fine 🙂
    3: Debugging… lldb works for me, node's debugger is fine, and XDebug are quite cool. So… i got that down. Also, I do git.
    4: Definitively got THAT down 😀 I actually loved scribbling "BASHful" in the corner of my pages at school just to confuse people ^^.
    5: Anti-Social skills. Wat. That caught me off-guard… But once I understood what you mean, it made perfect sense. In fact – I am visually impaired and suck at communicating face to face…so I use emails and stuff. So, definitively something I got down by nature, in fact.

    Welp, now I feel confortable! Thanks for sharing these tips 🙂 Always great to hear about hints and tips by other guys.

  • WC Moffatt says:

    He should get an aero press. It takes like a minute longer than instant coffee and doesn't taste like crap.

  • Michael Negraru says:

    TechLead, I know you mention learning SQL DB. But is learning NoSQL DB just as good? I'm talking about Mongo.

  • Emrah Duru says:

    Is there a German version of the techlead on yt?

  • John Weck says:

    Greetings, good video. Some advice for everyone:

    a. Dump the caffeine habit (along with any other drug habits like ethanol, nicotine, pot, etc.). It takes a couple of months for the withdrawal symptoms to end, but it’s worth it. Remember, software reflects the person that made it. “Garbage in, Garbage out” applies to people too.

    b. Learn how to write, and create meaningful (and concise) comments in your modules. Do this before you write the code, not after. This is what software reviewers will be reading. You will use this to understand your own software, especially after a few years goes by and you forgot everything on the project. An error in a comment is more important than an error in the code.

    c. If you create meaningful error checks and reporting in your code, they will do most of your debugging automatically when you first run the software.

    d. When you communicate with people at work, you have to realize that most of them are ignorant (stupid). They won’t understand a word you’re saying, and try to blow you off, the same way they blew off their teachers back in grade school. For the smart people, communicating is a pleasure. The only people having technical arguments are the ignorant people that all copycatted different things (typically trivial nonsense) from their different and wrong friends (sometimes decades ago). Remember, ignorant people copycat everything (but they don’t understand any of it).

    Thanks for listening. 🙂

  • Redbouquet Aida says:

    I am not a software engineer. Your advice is helpful to any junior engineer learning how to navigate the corporate world.

  • angella max says:

    Please make more videos on social skills required for programmers

  • The Whiz Kid says:

    Knowing how to actually read code is okay. Writing code is a learned Skill. And it depends on the programing language.

    Web development is also nice.

  • Jim says:

    good job hitting 10:07 with a solid minute of nothing at the start. dem ads bby

  • TheEsotericZebra says:

    Damn. Working as a web developer for about 6 months now, I can't help but agree with everything he said. I'm really glad I learned bash, but it does take some effort to step out of your comfort zone and write a script sometimes. But debugging skills are really critical. I need to practice using breakpoints…I'm still a console.log person

  • Hei Julian So says:

    What's tooling language and what's an example?

  • GTS- MEGHNI says:

    For me, I was focusing on :
    1.Regular expressions
    2.Handling errors
    3-Threading process

  • Feras Aaric says:

    A System To Achieve Every Programmer's Dream.
    https://tinyurl.com/y5geh6bc

  • Monna Ye says:

    Are you loyal to any coffee brand? Or do you have anyone suggestions for instant coffee?

  • Quentin Watt Tutorials says:

    Oh man.. the problem solving point.

    Too many people want to get into software development and not solve their own problems.

  • Xin Jiang says:

    well I thought anti-social skill would be some hacking skill~ didn't expect that

  • Steven Demartini says:

    some kidna 3rd hand skills I found very useful are. technical writing, documenting code, and processes, point of contacts all of it! good technical writing is SO SO SOOOO important and so valuable! some microsoft excel skills can go a long way too any spread sheet tool to look at data and set up input, output fles. reading spread sheets.

  • Альфред Гордан says:

    I hate that cup

  • Hugo Hackenbush says:

    A while back I had a huge breakthrough in my career as a software engineer. My neighbor gave me his Keurig machine.

  • Gora Elec says:

    I'm a tech support engineer and have all 5 skills. Am I doing something wrong with my life?

  • Muhammad al-Khwarizmi says:

    Re: tools: I have a script that makes a fresh Debian environment comfy in a matter of mere minutes (depending on network and processor speed) and all I have to do is confirm a few things manually. Everything else is entirely automated:

    https://github.com/readyready15728/misc/blob/master/setup.sh.md

    I have thought about eliminating even these steps with Expect or a similar tool. It's not urgent but I might do that some day.

  • Adam Gao says:

    got 1,2 and 3. going for 4 today

  • Fernando Guillén Suárez says:

    You have to choose 5 things and the first you choose is "Regular expressions" :/ boooring

  • Thea Mjolnir says:

    3 cups of instant coffee lol that's a lot less than I drink.

  • E Ho says:

    lavazza coffee, tech lead, you will only need one cup a day

  • Mali Hali says:

    Can I borrow your brain?

  • Gabriel Chartier says:

    You aren't a good developer unless you write and use your own version of git just like our lord and savior TechLead

  • Janeen Andersen says:

    Dear TechLead, I am looking for a real life question used by a programmer involving quadratic equations?

  • Von_Geist says:

    If you don‘t code on some form of linux it‘s hard to take seriously when you mention tooling. Tiling wm, package managers, tooling are only crutches on mac compared to linux. On mac, Gpu server with remote development to increase coding effectiveness for the tons of do-once stuff is just not possible. Do a big query in redis no problem. Get a result fast. Efficient code can cost much more than hardware and is only useful when it causes a runtime bottleneck.

    If anything coding is about doing the right things much more so than doing things right/neatly. Good code is mostly about not hurting / slowing one-self and minimizing having to fill in for others incompetencies/ workloads.

  • Rick Coker says:

    The compiler is wrong 😂

  • sbong says:

    great video always 🙂

  • rolmops says:

    I've been a programmer for about a decade now, and I have to say, there's one key requirement that none of these lists ever seem to mention. I'll go down the list given here, and hint at what that one key thing is:

    1. Regex -> True, a lot of juniors are a bit mystified, and even a bit taken aback when they stumble across code that is heavily reliant on regular expressions. This, I think, is where the inherent trait that makes people last as programmers should kick in. It took me a bit of time at first, but I got stuck in, and now write regex with ease. More importantly: I also know when not to use them.
    2. SQL -> I hated it at first, and still don't like SQL very much. It's part of the job, and you learn it to the point where you don't have to think about what you're doing. Much like you learn how to write after you learn how to speak. You know what data you want, you simply have to learn how to get the data in the best way possible (all things considered). One of the most common way to do this is to write SQL queries and understanding indexing etc…
    3. Debugging -> Very true. Juniors rely on printing statements, dumping stuff, and running the application they're working on locally. This works for simple tasks, but when you grow in your career, you'll find yourself in situations where you can't simply get by on simple debug statements. The usual transition from "amateur debugging" to using an actual debugger goes something like this: You curse, you wade through pages of ancient documentation (especially when having to learn a tool like gdb). Gradually, you stop thinking about it, you just do it. It makes sense. You have now learnt not only how to use a debugger, but more importantly: you've come to understand the importance of tools like this.
    4. Tooling -> Again, I'd argue that this is a diplomatic way of repeating the good old programmers adage: be cleverly lazy. If you find yourself doing the same thing over and over again, automate it. As you grow as a programmer, you inevitably end up reading through other people's scripts. Soon, you'll find that a particular script almost does what you need it to do. You mess around with it, tweak it, maybe add a CLI flag or two, and before you know it, you've learnt the basics of another scripting language. I've never spent a great deal of time learning Perl, Python, or even Bash. Weirdly, I've probably got about 100 scripts somewhere that I've written over time, and kept just in case. Some of which I've worked on as time progressed, and I now use on a daily basis.
    5. Anti-Social skill -> This is not really a skill, I think, as it is a trait shared by many programmers. A significant part of the job is wrestling with quite complex business logic, while at the same time keeping an eye on cost (WRT system resources, runtime overhead, etc…). The last thing you want is to be disturbed when you're trying to get to grips with something. Like is the case with most jobs, you have to reach the point where you're comfortable telling people to GTFO, because you're busy with something more important. If that person is a programmer, too, most of the time they'll understand. You don't have to explain it. I often just don't look at them, raise my hand and shake my head. The people I work with quite quickly understand that this isn't something to take personally. It's just that I'm not in a position where I can easily switch contexts. Context switching is expensive in computing as it is in real life.
    The best thing about this is indeed that you'll end up communicating in written form a lot, which has the accidental benefit that your ticketing systems, wiki's and README.md files become a very valuable resource of documentation, not just on the code that's there, but also gives you an insight on the problem analysis that was made at the time of implementation, and what compromises were made, and why. Read through this information, and you'll be up to speed with a new project in no time. Again, this is something you learn to appreciate over time, and indeed find yourself doing. I initially found documenting stuff a royal PITA, a waste of time. Nowadays, there will be days that I tell my colleagues that I'll be updating docs that day.

    So, what is the key requirement that I would like to see more in these lists? Well, let's look at what I wrote, and see if we can spot a theme:

    1. Regex: You learn it on the job, and you approach it as a challenge to become a better engineer. You want to learn new things.
    2. SQL: You need data, and you find yourself needing to learn the best way to get at it. You embrace the tool, flawed though it may be, and make it work for you.
    3. Debugging: You find out that your rather naive and childish approach to try and figure out what's going wrong isn't cutting it anymore. You hear about a complex tool, and invest time and effort into learning it. You get used to it, and begin to wonder how you've ever managed without it. You've now learnt something new, and add it to your toolchain. Another skill mastered, and you feel good about yourself (perhaps even smug when you see another junior who's yet to reach that point).
    4. Tooling/scripting: You feel like you're wasting time doing a lot of repetitive, boring tasks. You don't want to be doing that, so you find a way to make your life easier, and learn the power of scripts. That means learning another language (most of the time), which isn't a big deal anymore. After all, you've already mastered regex, SQL, and gdb… how hard can it be. Besides, it's yet another skill you can add to your resume, and maybe you can use it in a pet project some day… Learning is fun, isn't it?
    5. You've learnt a lot by now, and people who start out and are still stuck at the first obstacle could do with a bit of guidance, so you decide to create a wiki page documenting certain scripts you wrote. You start doing pair programming, and you also find that you need to safeguard your own time. You feel like you've earnt a certain level of respect, so you're not at all shy to tell people to leave you alone for now. When complex things are discussed verbally, you write them down. Initially for your own benefit, after all: it's been discussed, you don't want to have the same discussion with another person. Create a wiki page, and occasionally check the comments underneath, and have a good old back and forth when it's convenient for you. It's all written down, so everyone can catch up with the discussion and chip in.

    OK, so in all 5 points, LEARNING seems to be a recurring theme. You have to acknowledge it when you don't know something, but rather than give up, you have to WANT to learn. IMO, everyone can learn how to write working code. Not everyone enjoys a job that requires you to never stop learning. Like I said: I've been a programmer for a decade now, and I still absolutely love my job. Not because I like typing code, but because I enjoy looking back at where I was just a year ago, and conclude that I know a lot more now than I did back then. Just like I'm sure that a year from now, I'll look back at what I know now, and say to myself "Damn, if only I would've known that a year ago".

    Programming is something you can learn in a matter of weeks/months. Being a programmer is spending the rest of your days endlessly learning how to become better at it. Being a good programmer means that you know that this quest for perfection is never going to end, and it's exactly that what makes you love the job even more.

  • daniel jimenez says:

    I feel a bit sorry that you consider freeze-dried instant coffee "good stuff".

  • NintendoGamer789 says:

    Someone should make a compilation of Coffee Time™

  • Bhavneet Sachdev says:

    All of these skills are taught or you acquire them doing projects in most grad schools nowardays.

  • Keylan Shannon says:

    damn that coffee looks good.

  • Nolan Luckett says:

    This channel is sooo dangerous, LOL. I wonder how many people have gone to work after watching and started writing their own version control system?

  • W0lfbane Shika says:

    Is one of those becoming a Coffee Addict?

  • roger EPSILON says:

    what is the desk lamp u have behind u at 9:54?? Love the content men.

Leave a Reply

Your email address will not be published. Required fields are marked *