Name: 5 must have skills to become a programmer (that you didn't know)
Uploaded: 2020-03-27T18:45:28.000Z
Duration: 10 min 8 s
Description: Thousands of YouTube videos with English-Chinese subtitles! Now you can learn to understand native speakers, expand your vocabulary, and improve your pronunciation...

Hey, tackle a tear and welcome back to another episode.

At this rate, I'm drinking about three cups of coffee every day, and you may be thinking, What?

That's pretty unhealthy, but it's not, actually, because if you check the ingredients is just coffee, instant coffee.

So, you know, I could 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 university students.

People are just getting into tech trying to become programmers and people who aren't necessarily aware of all the skills that may be required or needed for the field.

You know, we all know the obvious ones, right?

Like you know how the program you need to learn a language and maybe you need some communication skills, do some problem solving white boarding over them.

And it might be actually for you two passes or an 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.

But over time you realize that every single software engineer took the time to learn these things.

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.

Other 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 basis for certain pieces of text using tools like grab, you know, many code editor's support.

This, like supply and visions through the O code, regular expressions or rejects, is often used for searching across large code base is doing search and replaces re factoring code.

They can even be used as co checks to prohibit committing certain strings of text certain styles of coding Using regular expressions.

You could scrape websites parts for data, create entire Web applications where you read that day that validate the user input, store the data in a certain format and then read that format back.

You can do all of that with the regular expressions.

Every single company F worked in has depended heavily on regular expression.

If you're not familiar with them, I recommend you have a gun on board moving on.

The second skill that most developers should know is sequel Love Developers FN, especially if they're junior.

They don't really know sequel yet, but eventually many developers would go on to learn sequel.

You know, sequel is a database languages for Korean database tables, creating tables, editing them, reading them and you might be thinking to yourself, or you're not a database engineer.

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.

And ELISA 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 application usage time by 2%.

It dropped some other metric by 1% but recovered that in some other way.

And sequel is essential for being able to quarry 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 is going to be helpful for any engineer to at least be able to write a few standard sequel quarries using, like, group by order by aggregation things like that.

The third skill that we all need is debugging skills.

All too often I see engineers that 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?

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 at the end, If I were in the coat of bug, maybe because for the majority of engineers, most of your task is going to involve fixing small bucks.

Figure out where it is and then fix that buck.

And many times these books can be obscure, kind of strange, hard to track down.

The ability to debug is going to be very important here.

But if you're working on same mobile APs, for example, you're going to want to be able to use that the bugger GTB, step through the program, create breakpoints, maybe even check out source control.

Check out the version history of a file and see where it changed at what version and where the issue may have first cropped up.

Oftentimes people would see me as the senior engineer asked me to go fix the problem that no one else can fix its not necessarily because I know some Albert and better than some other person is simply because I know how the debugging program more accurately and precisely is 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, I think, what really makes offer engineers highly productive.

The difference between engineer who's out putting one X code versus two ex coat or five X or 10.

Next coat is the tooling, and usually these tools are going to be written in a language.

You could really use, like know Js javascript, maybe ruby on rails or go late, some tool in language that could work well on the command line.

And you know these scripts can be used to help exhibit that your overall workflow, for example, For Cobra factors, you may be reading a script.

There's only a one time usage thing, and it can analyze a repositories of code and overall detect unused files, maybe buggy lines of code.

I personally write my own script rappers on top of version control.

So I'm not necessarily using, like, say, get or mercurial for version control.

I'm using my own system, and I find that that for me help speed up my personal workflow.

So I would just recommend that you not ignore descript inside.

This is going to involve maybe having some familiarity with bash the next UNIX.

And a language likes a 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 anti social skills.

And anti social skills are very important for a developer.

You know, if you just go to your coworker, James and you say, Hey, James, how's it going?

all of that is not really providing much value for anybody.

And James may even decline your invitation to go up 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.

You're anti social skills is really about communication without being social.

And this may involve writing emails creating wiki pages, posting two groups, said them power point presentations, creating Excel sheets and notes and properly circulating them.

You know, it's funny that I've worked in some companies where I'm my send the private message to somebody, and that person would explicitly declined 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, preserved the knowledge and circulate it with as many people as possible.

The proper form for that, maybe like a wiki or widespread email message or something like that, where many people can see the message and the conversation you know, this may also involved if you have a one on one conversation with somebody.

But after that you want to capture that conversation in the anti social manner in which you write down the notes off the meeting, the conversations and then you circulate that across your team so that everybody knows what was discussed.

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.