- don't be afraid to crack a joke, even in front of the CEO
but
- never at someone else's expense
Some of the best work relationships I made came after walking into a room of strangers and saying something like 'Hi I'm your architect, for all your pretty diagram needs!'. People want to connect to someone human and who can joke about the surreality of the work environment.
The importance of soft skills is underrated. Technical skills are important, sure, but I would much rather work with an "average", friendly teammate than an insufferable genius.
These are all great. I started writing the article with the intention of including the soft skills mentioned by everyone but it quickly became very long. Part two will have soft skills and I'll make sure to include your notes.
How can you learn the soft skill of having a backbone? Its something that I lack but it seems innate in my personality. I have no idea how to even begin to change it.
> - beware of premature optimization. Spend that time on defensive code, comments and tests. Optimize based on measurements, not feelings
In some contexts - rapid development and prototyping especially - defensive coding is not much different than premature optimisation. I fired a developer once, because he couldn't let go of his defensiveness whereas what the project needed was a buggy, proof of concept, version.
Also, offensive programming is a thing, and possibly less bug-prone in some situations:
This too depends on context and a team. Personally, I prefer argumentative people (within reason) to nice ones - the last thing I want is for a developer to do something he believes is stupid, and not tell me about it.
Having said that, being too argumentative is not good either - some devs seem to build their self esteem based on the number of arguments they won. No no no.
> - take notes when getting tasks and make sure you don’t miss anything
This is super-true. Also - read a tutorial on active listening. I had a team of developers once who literally made zero notes from the meetings.
> - be humble when getting criticism and be merciful when giving one
As for being humble when getting feedback - I'd add "don't afraid to ask as many questions as needed for understanding". There is a difference between being humble, and non-confrontational. The former acknowledges they may be wrong, the latter hides the fact that they think they are right.
> - count to ten before sending an angry / escalation email
Or just call instead.
> - don’t work yourself to death, have limits
But acknowledge that crunching - within reason - can be fun :)
Yeah setting limits may be the most important in general. That and staying positive. I've been a web dev since 1995, I lasted this long by setting limits and seeking out companies with reasonable work expectations. Its only worth it to jump into a startup if you're a member of the board of directors. Startup work is good to get your foot in the door but after a year or two of that you're going to want to find a larger company with more stability and sanity, unless you own a portion of the startup where the intense work makes it financially worth it.
I don't know that these are learned the same way learning how http works is learned, because it requires an emotional shift and a shift in how you already view the world.
These changes are transformative, not additive - unlearning can be a lot harder than learning.
Excellent list otherwise.
Most of these things will become 'natural' if you spend time around people who've already internalized these lessons, so for the younger folks, the greatest help would be getting to spend time with people who already have these qualities - it'll slowly mold you into having them as well.
We had a problem for a while with people who not only didn't have those soft skills, they didn't have "business sense". They were out to maximize their own experience and didn't care what the business needed from them. Like closing a lot of tickets but doing the job poorly, so they caused other problems or didn't even fully solve the first problem. They did this because they thought their job was to close tickets, no matter how many times we told them it was to solve problems.
This is an excellent list. I actually fired off a snarky reply to a snarky work email just before reading this. Thanks for reminding me to check myself.
It's a good list, though these particular things are more about functioning at a basic level than standing out.
Speaking more generally, the best reason to learn anything is always "so you can do shit" rather than some calculated competitive motivation to impress someone. The latter attitude reminds me of the 80s somehow, and yes I'm old enough to remember. It doesn't bring joy. Neither does being told there might be thousands (bold type and everything) of people competing with you. Just focus on mastery, have fun, and let "standing out" happen on its own.
No kidding. I was blown away by the notion there are working web devs who don't understand HTTP or basic networking.
I feel like this advice could be summed up in one sentence, "Create at least two good full stack web applications for your portfolio, put them in your git, use different languages for each and a minimal IDE."
The best advice to stand out has already been said here, soft skills that complement fundamental technical competence. Once you're in an interview understanding basic human empathy and having a strong and apparent capacity to work with a team has way more persuasion than bullet points on your resume.
I got the same impression. I'm still a student and have a decent grasp of all of these things from my prior internships. I thought that some of these skills were not standout, but rather mandatory in order to work full time as a web developer. I guess I have nothing to worry about.
If bootcamps trend upwards to overtake traditional 4 year curricula, then this list will absolutely make them stand out. Those courses are hyper-focused on essential OJT basics that they wouldn't have time to incorporate a lot of this information.
While I don't dispute that this article lists good knowledge to have, I don't think it qualifies as useful career advice (which seems to be the intention).
Want to stand out in web development? Specialize in something useful that few other people are. The best way to do that is to learn some technology that all your peers hate.
"Pfft Java? Nobody uses Java anymore, you should learn Vue.js instead it's the new hotness" + "Companies are still hiring Java programmers" -> Learn Java, the herd is going away from it but the demand is still there.
I agree that picking a skill the market needs is sound advice, but I have a minor quibble here. I think self taught devs shouldn't focus on Java as an on-ramp into the job market, because it places them in direct competition with recent CS grads who learned Java in school, and with low cost offshore shops. I doubt you want to be in the low end (skill wise) of that market. Now, being well versed in Scala, Angular, or various flavors of SQL would be a solid way to differentiate while still targeting industry needs, IMO.
Don't forget about the swaths of experienced Old Technology(TM) people already in the market. Nobody wants to learn PHP for the first time, but anyone with more than 10 years of webdev experience probably already knows it.
Realistically, if you're just starting out, learning the New Hotness is probably not a bad idea as it puts you on more of a level playing field.
Shouldn't most of these be standard skills that a web developer should know? I think _not_ knowing these things would make you stand out more than if you knew them (albeit, negatively). Perhaps I'm missing something...
Not necessarily. For example you could be a decent web developer on the Microsoft stack and not be proficient with the whole section "Learn To Work in Unix Shells". Also it could be easy to get by using git with a UI and not know any of the commands or medium/advanced functionality.
These are all good skills to be proficient on day one.
What I don't see listed that I would prioritize above some of these (because every environment is different so skills are sometimes different) is testing discipline. Have you written a unit test before? Can you write testable code?
That is a much harder set of concepts to understand and would likely take awhile. Make sure what you put up is tested - that would separate you quite a bit.
> Get familiar with a command line text editor (vim, Emacs, nano, …).
Can someone explain to me why it would be beneficial to learn these? Most of the time if you needed to edit some file couldn't you just <fav text editor here> file.*? I am trying to understand this. Thanks
Its handy to be able to make changes on remote servers there and then without too much messing about.
E.g if you are connected to a remote server and you need to change a file, how do you do it with say VSCode or Sublime etc? Download it to your machine, edit it, save it, then re-upload? Sure that works for the occasional once-a-month kinda thing, but it is a bit convoluted.
It is much easier and faster to just edit the file there and then on the server. Especially if you are doing multiple changes.
Vi really is very simple - you just need to remember esc, i, x and :wq and that is basically all you need to know to be able to do basic edits a file on pretty much ANY server you'll ever connect to (except perhaps windows or a super-stripped down cloud image).
It's useful when working with remote servers that may not have a graphical interface at all. There's rsync and network drives are sometimes an option but it's very convenient to just ssh into a server and edit/view with vim directly.
In the cases of vim/emacs, people who dive deep enough will often find them superior than <previous fav text editor>.
I asked Web Developers across several communities what skills they thought were often neglected by new Web Developers
Knowing git would be great, knowing HTTP would help if you're going to be working with APIs, and knowing dev tools would be useful if you're more front-end. I'm not sure the rest (networking, UNIX, another language and commenting code) are really things that would tip the balance in your favour.
Particularly the additional language - I'm sure most web software companies would rather a candidate knew more about the main languages used to build web things (HTML, CSS, JS, [Node|Ruby|PHP], and SQL) than something 'extra' that they're unlikely to use if only one dev knows it.
> I'm not sure the rest (networking, UNIX, another language and commenting code) are really things that would tip the balance in your favour.
As someone who sits more on the Ops side of DevOps in his current day job, developers who can say "df said the disk is full", "when I try to connect to it, it times out while connecting and we don't even get a syn/ack back, but it works fine from my phone", etc... I want to hug them. Additionally, I came across this comment the other day while debugging a firewall issue:
// FIXME, we probably want to make this more robust since if it fails on startup it will never be good until we restart.
I was pretty upset to discover that the things I had been trying were all pointless, since I wasn't restarting the server every time, but that single line comment was the enlightenment I needed to solve the problem.
> Particularly the additional language - I'm sure most web software companies would rather a candidate knew more about the main languages used to build web things (HTML, CSS, JS, [Node|Ruby|PHP], and SQL) than something 'extra' that they're unlikely to use if only one dev knows it.
I think knowing things outside of just the web languages is the difference between someone who has pigeonholed themselves as a "web developer" vs. the more general "developer". Going for questionable analogies, I'd way rather have a "mechanic" than a "car mechanic" ("Oh? That's a 1/4 ton truck? Sorry, I only work on cars")
Knowing Unix/Linux command line tools will broaden the foundation upon which your other knowledge is built.
Knowing those tools will also simplify local development if you're running code in dev/test VMs or even containers.
Plus web dev is dealing a lot in text. Unix command line tools deal a lot in text.
I am, of course, biased as all heck. I'm a Unix sysadmin who does devops stuff too, so I like to think everyone should know the same thing as me.
Networking is vital too. Being able to understand just basics of what should be happening in a local subnet is very useful. Knowing about TCP ports and their states can also help debug certain problems.
All those extras make you stand out as a hyper-producer or guru rather than a run of the mill never stand out from the pack developer. There's definitely room in the world for both types, but gurus get the attention and respect.
Simple networking knowledge is a go-to interview question for me.
If you don't understand the basics of what happens from the time you enter a request in the browser to when the page fully renders you won't be very good at troubleshooting some basic issues. (Can't reach the server. Some content is missing. Is it timing out. How many requests are generated by a page.)
Really? I haven't done web dev in many years but these were all skills I had mastered before even attempting to define what type of development I wanted to do.
If web developers don't already all know this then what knowledge do they have nowadays? Just intimate trivia details of whatever framework/platform is hip this month? Is that all they work on?
Remember, it’s not about learning a language that will get you a job. It’s about broadening your horizons as a developer and being able to recognize the right tool for the job.
It's almodt always about getting a job. Why not concentrate on a language that makes you immediately employable?
I am a full stack dev in Microsoft world, been working with .net for 10+ year. Just started to gather skills to disconnect from ms and move my career fw as a front end dev.
Thanks for putting together this list, it terrifies me !
My situation is opposite: I know many things but React/Vue/Angular. It is interesting how the remote job market turned away fast from mobile development. I have elected to learn React and Vue, hoping to bet on the right horses :)
In most cases, you really don't need to know most of these. Depending on where you're working, most places have s dedicated team for networking, they have a whole teams dedicated to working on Linux servers, they have whole teams who only do database stuff.
For me, these are more "nice to have" skills than anything that will make you stand out. You should know how HTTP works, you should know how to use GIT. If you doing any modern web development, you should already completely familiar with the command line.
Most of the time when you talk with recruiters or hiring managers, they're looking for more of a "culture fit" which translate to developers with soft skills and a decent personality. A company can always mold a developer to how they do things and the tools they use, but it's a lot harder to change a shitty personality.
Are there any modern tricks for debugging against a TLS website? Last time I was doing it 5 years ago we did mitm proxies, ssl self-signed tricks, to get wireshark able to sniff and read the payload.
[+] [-] eranation|7 years ago|reply
- check yourself before blaming others, it might eventually be an issue in your code
- beware of premature optimization. Spend that time on defensive code, comments and tests. Optimize based on measurements, not feelings
- take notes when getting tasks and make sure you don’t miss anything
- ask questions when stuck but don’t ask things before at least googling them once
- under promise and over deliver
- be nice and never argumentative
- be humble when getting criticism and be merciful when giving one
- count to ten before sending an angry / escalation email
- understand that some people need to have things explained to them slowly and more than once, be patient
- have some backbone eg, if your manager is wrong, tell them (in private!) but accept if they don’t agree, they have the final word.
- be proactive and communacte your status and plans even if not asked to
- don’t work yourself to death, have limits
[+] [-] dingaling|7 years ago|reply
but
- never at someone else's expense
Some of the best work relationships I made came after walking into a room of strangers and saying something like 'Hi I'm your architect, for all your pretty diagram needs!'. People want to connect to someone human and who can joke about the surreality of the work environment.
[+] [-] fiveoak|7 years ago|reply
[+] [-] CiPHPerCoder|7 years ago|reply
Having some backbone and some tact is a good thing, but never showing backbone outside of "(in private!)" isn't always the right answer either.
I think it's better to learn to read the room and know when it is or isn't appropriate to raise your objections in a somewhat public manner.
Defaulting to privately when in doubt is a good strategy, but sometimes you have to call a spade a spade or the whole company suffers for it.
[+] [-] digitalsushi|7 years ago|reply
"If you explain slowly I will learn quickly"
[+] [-] darkstar999|7 years ago|reply
[+] [-] bloopernova|7 years ago|reply
You'll get a much better result, too. They won't be super defensive because they weren't called out in front of a dozen people.
[+] [-] cmorgan8506|7 years ago|reply
[+] [-] plopz|7 years ago|reply
[+] [-] kolinko|7 years ago|reply
In some contexts - rapid development and prototyping especially - defensive coding is not much different than premature optimisation. I fired a developer once, because he couldn't let go of his defensiveness whereas what the project needed was a buggy, proof of concept, version.
Also, offensive programming is a thing, and possibly less bug-prone in some situations:
http://johannesbrodwall.com/2013/09/25/offensive-programming...
> - be nice and never argumentative
This too depends on context and a team. Personally, I prefer argumentative people (within reason) to nice ones - the last thing I want is for a developer to do something he believes is stupid, and not tell me about it.
Having said that, being too argumentative is not good either - some devs seem to build their self esteem based on the number of arguments they won. No no no.
> - take notes when getting tasks and make sure you don’t miss anything
This is super-true. Also - read a tutorial on active listening. I had a team of developers once who literally made zero notes from the meetings.
> - be humble when getting criticism and be merciful when giving one
Just not too merciful :) A good book on managing people, including giving feedback: https://www.amazon.com/Radical-Candor-Kim-Scott/dp/B01KTIEFE...
As for being humble when getting feedback - I'd add "don't afraid to ask as many questions as needed for understanding". There is a difference between being humble, and non-confrontational. The former acknowledges they may be wrong, the latter hides the fact that they think they are right.
> - count to ten before sending an angry / escalation email
Or just call instead.
> - don’t work yourself to death, have limits
But acknowledge that crunching - within reason - can be fun :)
[+] [-] shams93|7 years ago|reply
[+] [-] alexashka|7 years ago|reply
These changes are transformative, not additive - unlearning can be a lot harder than learning.
Excellent list otherwise.
Most of these things will become 'natural' if you spend time around people who've already internalized these lessons, so for the younger folks, the greatest help would be getting to spend time with people who already have these qualities - it'll slowly mold you into having them as well.
[+] [-] wccrawford|7 years ago|reply
[+] [-] khedoros1|7 years ago|reply
You're just jumping ahead of the second part of the list ;-)
[+] [-] braindongle|7 years ago|reply
[+] [-] rdiddly|7 years ago|reply
Speaking more generally, the best reason to learn anything is always "so you can do shit" rather than some calculated competitive motivation to impress someone. The latter attitude reminds me of the 80s somehow, and yes I'm old enough to remember. It doesn't bring joy. Neither does being told there might be thousands (bold type and everything) of people competing with you. Just focus on mastery, have fun, and let "standing out" happen on its own.
[+] [-] camelCaseOfBeer|7 years ago|reply
[+] [-] Meegul|7 years ago|reply
[+] [-] noxToken|7 years ago|reply
[+] [-] CiPHPerCoder|7 years ago|reply
Want to stand out in web development? Specialize in something useful that few other people are. The best way to do that is to learn some technology that all your peers hate.
"Pfft Java? Nobody uses Java anymore, you should learn Vue.js instead it's the new hotness" + "Companies are still hiring Java programmers" -> Learn Java, the herd is going away from it but the demand is still there.
[+] [-] ch4s3|7 years ago|reply
[+] [-] mywittyname|7 years ago|reply
Realistically, if you're just starting out, learning the New Hotness is probably not a bad idea as it puts you on more of a level playing field.
[+] [-] cryptozeus|7 years ago|reply
[+] [-] camelCaseOfBeer|7 years ago|reply
[deleted]
[+] [-] ryannevius|7 years ago|reply
[+] [-] cmorgan8506|7 years ago|reply
[+] [-] titanix2|7 years ago|reply
[+] [-] darkstar999|7 years ago|reply
[+] [-] walshemj|7 years ago|reply
[+] [-] sailfast|7 years ago|reply
What I don't see listed that I would prioritize above some of these (because every environment is different so skills are sometimes different) is testing discipline. Have you written a unit test before? Can you write testable code?
That is a much harder set of concepts to understand and would likely take awhile. Make sure what you put up is tested - that would separate you quite a bit.
[+] [-] ovrdrv3|7 years ago|reply
Can someone explain to me why it would be beneficial to learn these? Most of the time if you needed to edit some file couldn't you just <fav text editor here> file.*? I am trying to understand this. Thanks
[+] [-] mattlondon|7 years ago|reply
E.g if you are connected to a remote server and you need to change a file, how do you do it with say VSCode or Sublime etc? Download it to your machine, edit it, save it, then re-upload? Sure that works for the occasional once-a-month kinda thing, but it is a bit convoluted.
It is much easier and faster to just edit the file there and then on the server. Especially if you are doing multiple changes.
Vi really is very simple - you just need to remember esc, i, x and :wq and that is basically all you need to know to be able to do basic edits a file on pretty much ANY server you'll ever connect to (except perhaps windows or a super-stripped down cloud image).
[+] [-] albemuth|7 years ago|reply
In the cases of vim/emacs, people who dive deep enough will often find them superior than <previous fav text editor>.
[+] [-] onion2k|7 years ago|reply
Knowing git would be great, knowing HTTP would help if you're going to be working with APIs, and knowing dev tools would be useful if you're more front-end. I'm not sure the rest (networking, UNIX, another language and commenting code) are really things that would tip the balance in your favour.
Particularly the additional language - I'm sure most web software companies would rather a candidate knew more about the main languages used to build web things (HTML, CSS, JS, [Node|Ruby|PHP], and SQL) than something 'extra' that they're unlikely to use if only one dev knows it.
[+] [-] tonyarkles|7 years ago|reply
As someone who sits more on the Ops side of DevOps in his current day job, developers who can say "df said the disk is full", "when I try to connect to it, it times out while connecting and we don't even get a syn/ack back, but it works fine from my phone", etc... I want to hug them. Additionally, I came across this comment the other day while debugging a firewall issue:
I was pretty upset to discover that the things I had been trying were all pointless, since I wasn't restarting the server every time, but that single line comment was the enlightenment I needed to solve the problem.> Particularly the additional language - I'm sure most web software companies would rather a candidate knew more about the main languages used to build web things (HTML, CSS, JS, [Node|Ruby|PHP], and SQL) than something 'extra' that they're unlikely to use if only one dev knows it.
I think knowing things outside of just the web languages is the difference between someone who has pigeonholed themselves as a "web developer" vs. the more general "developer". Going for questionable analogies, I'd way rather have a "mechanic" than a "car mechanic" ("Oh? That's a 1/4 ton truck? Sorry, I only work on cars")
[+] [-] bloopernova|7 years ago|reply
Knowing those tools will also simplify local development if you're running code in dev/test VMs or even containers.
Plus web dev is dealing a lot in text. Unix command line tools deal a lot in text.
I am, of course, biased as all heck. I'm a Unix sysadmin who does devops stuff too, so I like to think everyone should know the same thing as me.
Networking is vital too. Being able to understand just basics of what should be happening in a local subnet is very useful. Knowing about TCP ports and their states can also help debug certain problems.
All those extras make you stand out as a hyper-producer or guru rather than a run of the mill never stand out from the pack developer. There's definitely room in the world for both types, but gurus get the attention and respect.
[+] [-] bartmcpherson|7 years ago|reply
[+] [-] walshemj|7 years ago|reply
[+] [-] majewsky|7 years ago|reply
[+] [-] crunchlibrarian|7 years ago|reply
If web developers don't already all know this then what knowledge do they have nowadays? Just intimate trivia details of whatever framework/platform is hip this month? Is that all they work on?
[+] [-] scarface74|7 years ago|reply
It's almodt always about getting a job. Why not concentrate on a language that makes you immediately employable?
[+] [-] cryptozeus|7 years ago|reply
Thanks for putting together this list, it terrifies me !
[+] [-] svdr|7 years ago|reply
[+] [-] epx|7 years ago|reply
[+] [-] at-fates-hands|7 years ago|reply
For me, these are more "nice to have" skills than anything that will make you stand out. You should know how HTTP works, you should know how to use GIT. If you doing any modern web development, you should already completely familiar with the command line.
Most of the time when you talk with recruiters or hiring managers, they're looking for more of a "culture fit" which translate to developers with soft skills and a decent personality. A company can always mold a developer to how they do things and the tools they use, but it's a lot harder to change a shitty personality.
[+] [-] digitalsushi|7 years ago|reply
Did anyone invent an easy way to do this?
[+] [-] mythrwy|7 years ago|reply
Are there many web developers who don't know about these things?
[+] [-] poulsbohemian|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] aditya5670|7 years ago|reply
new web tutorial