- 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
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.
All the best companies I've worked for have had a bias toward hiring people who will easily fit in. People with small egos, people who want to help, people who show up.
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.
"If you explain slowly I will learn quickly"
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.
"It's perfectly acceptable to insult someone in private. Sometimes they might even thank you for it afterwards, but when you do it in public, they tend to think you are serious."
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 :)
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.
You're just jumping ahead of the second part of the list ;-)
- writing tests - understanding cache
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.
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.
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.
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
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).
As long as I have nano or can apt-install it then I'm happy to ssh in and do it that way; but it doesn't seem more convoluted to use GUI tools necessarily.
In the cases of vim/emacs, people who dive deep enough will often find them superior than <previous fav text editor>.
> In the cases of vim/emacs, people who dive deep enough will often find them superior than <previous fav text editor>.
Yeah after reading so many vim vs. emacs memes I was really surprised when my git commit message opened one of them for the first time. ( I didn't surround the message in quotes or something.)
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.
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?
Read the article's title. This article is clearly aimed at people who are starting to learn web development. It is not aimed at experienced web developers.
> ...these were all skills I had mastered before even attempting to define what type of development I wanted to do
Many people learn how to program by working on projects they want to work on, and a lot of people want to build web applications.
If you don't know DNS, how did you get a website in the first place to start working on.
If you know how to code, you probably know how to get your changes onto the website with GIT.
And if you have made a website before you probably know how to use Chrome Dev or Firebug.
All this stuff except the HTTP, and Network Debugging would be covered in the first two weeks of any coding bootcamp.
It's almodt always about getting a job. Why not concentrate on a language that makes you immediately employable?
I would think for instance for the middle tier - Python, Java, C#, Node JS
Python seems to be the easiest - I just learned it two weeks ago. Then Java or C# and finally Node.
I would think Node would be the hardest to learn because of how it is structured.
Thanks for putting together this list, it terrifies me !
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.
Do realize, the days of throwing your code over the wall and letting those teams deal with the underlying pieces are over
Did anyone invent an easy way to do this?
Are there many web developers who don't know about these things?
new web tutorial
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.
- Stuff that HN loves because it's new and exciting
- Stuff that companies generally hire for
If I find I am not standing out as a Python developer I could very well decide to learn either Vue or Java to stand out. Either language is still within the world of web development and would key in with existing skills and knowledge. What wouldn't make sense would be apprenticing in carpentry, that's not going to help you stand out as a web developer.
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.
> 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")
A web developer who knows to try the issue from a different machine and a different network is so much more useful to those around them. Makes work much more smooth, and speeds up development too.
In a choice between two candidates for a web dev role it's going to come down to who's shows more interest in (say) CSS layout technologies or writing webpack plugins than any amount of UNIX knowledge. There's a minimum amount they'd need to know like navigating around a CLI and using NPM, but I certainly wouldn't expect a developer have any sort of sysadmin skillset.
I'm not suggesting it's bad to know them or that they're not nice things for a developer to have, just that I don't think they have any significant impact on the chances of getting hired.
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.
"Is X possible?", "I like it, but are there any other possibilities?", "That sounds fun, but have we looked to see if there are any available tools that we could leverage", etc.
These are all the types of questions you'd expect a clueful manager to ask the people under him, but they actually work pretty well to guide a superior who thinks they have an answer, but you know it to be the wrong answer. They have to arrive at the new answer themselves, and implying that there is a better answer (such as 'did you know that a tool exists and does all the stuff you are planning') will cause them to be defensive. Let them work their way to the solution themselves, though, and they'll sing its praises for you.
Yep. I already thought of everything.
I ended up seeing both sides of this - I taught myself PHP and MySQL for a project I worked on for 3 years of college in my spare time...while I was learning Java and going through the CS program.
When I came out, oddly enough I ended up getting a PHP job despite spending a lot of time "wanting" a Java job. Definitely got to experience both sides of that coin.