Learning Web Development? Skills to Make You Stand Out(fullbit.ca)
fullbit.ca
Learning Web Development? Skills to Make You Stand Out
http://fullbit.ca/learning-web-development-stand-out/
99 comments
- 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.
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.
I sure hope that, as an achitect, you can do more than just pretty diagrams ! ;)
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.
> In the second part of this article, we’ll review a similar list, but for soft skills. Until then, happy learning!
You're just jumping ahead of the second part of the list ;-)
You're just jumping ahead of the second part of the list ;-)
I'd add:
- writing tests - understanding cache
- writing tests - understanding cache
someone on my team said this to me and i fell in love with the phase.
"If you explain slowly I will learn quickly"
"If you explain slowly I will learn quickly"
Is her/his native language Hebrew by any chance? :) I love this phrase and it sounds like a literal translation of the common Hebrew saying: ״תסביר לאט אני אבין מהר״
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.
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.
^this this this! Hard skills can be learned, good soft skills are more difficult to incubate.
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.
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.
And the insufferable genius often produces shit code anyway since he has no concept of how to work together with other humans / write code for teams.
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.
> - 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:
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 :)
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 :)
Without more context, this seems very extreme: 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.
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.
Because you are not used to feeling uncomfortable, you avoid it. All change requires you to face your fears and just do it despite feeling uncomfortable.
I suggest thinking about this in a slightly different way. Don't tell yourself that not having this skill is innate to your personality - that's a belief founded in a fixed mindset. Try to adopt a growth mindset on this issue. You have lots of little opportunities to stand up for yourself, which will over time add up to the ability to stand up for yourself when the stakes are high. I'm working on this issue too, and find the approach to be the most useful.
Start by noticing when it could be useful. You’ll (probably) find that there are plenty of low-key situations where you can assert yourself without being a jerk, and you can use them as practice.
Be polite, be kind, explain in a manner the consumer can understand - if you can't explain at their level, maybe you don't understand it well enough yourself.
> - 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.
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.
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.
Yep. This is aimed more at the OPs target audience (people who are learning web development) and I think being the person to call everyone out might be correct technically but not politically on your first day as a junior web developer. As you said, it's all about reading the room. I would rephrase it though to - ask questions, such as "what would you do if x happens" or "did you consider y as an alternative" or "did you know that tool z exists and does all that stuff you are planning to build from scratch" vs sentences that end with a period. It should never be in the form of "you are wrong and I'm right because of (list of facts/opinions/doesn't really matter as the person probably stopped listening already)"
For most managers, one level of indirection higher.
"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.
"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.
" ... ask questions, such as "what would you do if x happens" "
Yep. I already thought of everything.
Yep. I already thought of everything.
Being able to take someone aside after a meeting and tell them why they're wrong is an amazing skill.
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.
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.
This reminds me of what Ben Franklin said in the John Adams mini-series.
"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."
"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."
Brush your teeth (and tongue!), wear clean clothes, and comb your hair!
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.
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.
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.
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.
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.
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.
I prefer Kotlin and scala over Java and feel they'll eventually overtake most use cases for Java. But there's just so much more information out there for learning Java. If you know Java, it's just much easier to pick up all the other JVM languages. You can be productive but not idiomatic in Kotlin in a couple weeks. I continue to recommend to friends to learn java first, despite never using it when I have a choice.
From a foundations perspective, that makes sense. My comment was more about marketability of skills. I tend to tell people to learn Python or Ruby first, because there's a wealth of material, jobs (once you're good), low barrier to entry, and both languages are reasonably well designed.
That is a worthwhile insight IMO.
Maybe, it was a bit off the cuff, and I'd need to think more about it and look at some actually employment and pay data to have a better sense of the validity of the claim. However, I think in general looking for a exploitable niche is a solid plan.
I'd support the notion entirely though. There are so many Enterprise Java jobs that have the 5 years of experience qualifier that it's a significant impediment for a self-taught.
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.
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.
I had a similar experience with Ruby.
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.
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.
If you have time, learn the new hotness while you're employed for Boring Legacy Languages/Frameworks.
"You should learn vue.ja instead of java" ? Makes no sense...one is frontend, another is sever side. More like you should learn both.
They were chosen at random from two distinct buckets:
- Stuff that HN loves because it's new and exciting
- Stuff that companies generally hire for
As a 'web developer' you can pick your area of expertise. Nothing says that as a front end developer I can't learn Java and become full stack or backend. People can pivot within the world of web development.
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.
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.
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...
I think you'd be surprised what is left out when people come from unconventional backgrounds.
[deleted]
Yes, I also think these are standard skills; I have most skills listed here and I'm not even a web developer.
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.
To be fair if you truly understand how to use git with a UI you can probably pick up the console within an hour or two of some cursory googling.
I have worked with web developers and developers who didn't have the knowledge of how to use the command line or much if any networking.
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.
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
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).
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).
On KDE you can mount the SSH system as local and use your usual tool set. Or Krusader integrates an editor or passes off to Kate for editing (or kdiff3 for file compare or whatnot).
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.
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.
I'd say mounting a remote filesystem is convoluted when you can just edit with vi :-)
It's one click; it's not my normal way of working but one could make it no click, just needing connected to systems when not working on them (or monitoring) seems unwise.
Thank you for the response! Good to know.
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>.
In the cases of vim/emacs, people who dive deep enough will often find them superior than <previous fav text editor>.
Thank you for your reply!
> 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.)
> 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.)
100% this
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.
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:
> 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")
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")
Ditto on the problem reporting being so much more useful coming from someone who knows how to do just a little bit of investigation and diagnostics.
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.
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.
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
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.
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 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.
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.)
I would have thought a basic knowledge of SQL (basic selects and simple joins) and to be able to use the CLI to do these.
One of these skills is apparently "making a website that's completely blank on my phone" (FF for Android with uBlock Origin).
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?
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?
> If web developers don't already all know this then what knowledge do they have nowadays?
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.
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.
Ya... I don't get this article. I think the skills are good, but they aren't going to make you stand out.
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.
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.
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?
It's almodt always about getting a job. Why not concentrate on a language that makes you immediately employable?
I think the point is to do both. By broadening your horizons you will most definitely pick up other languages and techniques along the way.
I understand. But if you are just starting out, why not use the most in demand languages first prioritizing by what's easiest to pick up?
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.
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.
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 !
Thanks for putting together this list, it terrifies me !
Learn a little about AppSec: https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29...
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 :)
I was just starting to look for remote work and I was thinking about marketing my mobile (Android) skills to look for jobs. But I have been a web developer for the past 5 years (And 10 years before my switch to mobile for a few years). So you're saying its better to market my web skills rather than mobile?
From my desk, that's exactly how it looks. It may be the case that remote jobs are a biased sample.
what do you mean by "the remote job market turned away fast from mobile development"?
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.
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.
>In most cases, you really don't need to know most of these.
Do realize, the days of throwing your code over the wall and letting those teams deal with the underlying pieces are over
Do realize, the days of throwing your code over the wall and letting those teams deal with the underlying pieces are over
I agree the article is a bit of a laundry list but job search success is not about culture fit; technical screens and technical interviews are ubiquitous and critical.
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.
Did anyone invent an easy way to do this?
Did anyone invent an easy way to do this?
What are you reading that you can't read in the dev tools? You can see, edit, resend, and copy requests as CURL commands in both Firefox and Chrome. You can also see timing, some encryption stuff, and it's all in plaintext because it hasn't gone over the wire yet.
Ah, I remember. I had the model wrong. I was trying to view the HTTP payload of a remote client connecting to a remote server. We were trying to debug what was happening when clients were connecting to some enterprise appliances we didnt have the keys for. It has nothing to do with web development, but I mis-remembered what it was I used to work on. Ooops!
Safari has the ability to copy as curl now too.
charles proxy is not bad .. still have to do some self-signed stuff but it is fairly automated
These skills seem pretty basic for a web developer to have for most part (git, know about HTTP verbs, be able to use browser debug tools).
Are there many web developers who don't know about these things?
Are there many web developers who don't know about these things?
FWIW: cmorgan8506, the OP, is a quality freelance developer. Would hire again.
[deleted]
- 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