[eranation]

Adding to this: learn soft skills:

- 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]

- 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.

[baud147258]

I sure hope that, as an achitect, you can do more than just pretty diagrams ! ;)

[fiveoak]

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.

[monkeynotes]

^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.

[kahnpro]

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.

[CiPHPerCoder]

> - 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.

[eranation]

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)"

[lostcolony]

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.

[bjornlouser]

" ... ask questions, such as "what would you do if x happens" "

Yep. I already thought of everything.

[digitalsushi]

someone on my team said this to me and i fell in love with the phase.

"If you explain slowly I will learn quickly"

[eranation]

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: ״תסביר לאט אני אבין מהר״

[darkstar999]

Brush your teeth (and tongue!), wear clean clothes, and comb your hair!

[bloopernova]

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.

[BigChiefSmokem]

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."

[cmorgan8506]

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.

[plopz]

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.

[some_account]

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.

[doesitseeintome]

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.

[newfoundglory]

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.

[thorin]

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.

[kolinko]

> - 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 :)

[ken47]

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.

[shams93]

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.

[alexashka]

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.

[wccrawford]

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.

[khedoros1]

> 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 ;-)

[braindongle]

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.

[brimstedt]

I'd add:

- writing tests - understanding cache