Tangential to the post: sadly software engineering, along with other engineering disciplines, has a huge number of judgmental, rude, mean people employed in the profession. People who gaslight you...
Tangential to the post: sadly software engineering, along with other engineering disciplines, has a huge number of judgmental, rude, mean people employed in the profession. People who gaslight you for your (perceived) lack of skills, question your decisions snidely, or look down on you because they feel superior. These people are a stain on the industry.
I was one of these people for a while too. It took me a long time to embrace empathetic, considerate development—from caring about the end user, to being constructive and positive in code reviews. I don't entirely know how you solve the problem whether that's classes in being personable/caring at university, or just instilling positivity as part of a corporate style guide.
Regardless, there should be no space for such negativity or hurtful commentary towards others who are trying to climb the intellectual ladder. Give them a hand up, don't give the ladder sharp nails.
As a short aside. I want to shout out @Deimos who has made it easy for less experienced devs to contribute to Tildes. For me, even though I made some silly mistakes in my first PR, it was still...
As a short aside. I want to shout out @Deimos who has made it easy for less experienced devs to contribute to Tildes. For me, even though I made some silly mistakes in my first PR, it was still welcomed. Corrections were made and explained and my contribution - albeit small - was encouraged. As a result, I learnt something and feel encouraged to continue to improve. I have unfortunately encountered the other approach. Unsurprisingly it has the opposite affect. It’s easy to forget there’s someone on the other end of a review.
I hope I have a good perspective to add to for both you and @ThatFanficGuy and @emdash. I graduated 4 years ago with dual Bachelors of Arts in Mathematics and Computer Science from a small liberal...
I hope I have a good perspective to add to for both you and @ThatFanficGuy and @emdash.
I graduated 4 years ago with dual Bachelors of Arts in Mathematics and Computer Science from a small liberal arts school. A big part of liberal arts education is taking courses outside of your selected field. In order to graduate I had to take a lot of courses outside of STEM. I took a class on Theatre set design, 4 or 5 different religion classes, an English course, a Spanish course, a chemistry course, and another course that I know exactly what building I walked into on campus but I cannot for the life of me remember what it was this early in the AM. I would say the courses outside of my major are what make me a strong engineer and stand out more than anything I took within my degree. Since there is a focus on taking courses outside your major, that obviously means I took fewer courses than a traditional engineering program. There's only so many hours in a semester. It definitely made me slightly weaker in terms of programming. I don't know all the ins and outs of Linux or a complier in the same way some of my coworkers do. That said, I have a lot of strengths that they don't have that I learned in other courses. I am a lot better and communicating and working with the non-technical/non-engineers that come to our team in need of help, I am a lot better at writing clear, cohesive, useful documentation than a lot of others, I am better at problem solving, I am a lot better at seeing things from the user's perspective rather than just as purely an engineering problem to be solved. I give most of my team's presentations because I spent A LOT of time in college giving 15+ minute presentations on the relationships between cultures/historical events and religious texts and so I am very comfortable making longer presentations and delivering them. I spend more time thinking about UI and ethics than most my peers. I also have a really easy time learning and picking up new tech/projects because I'm really use to jumping into a subject I know nothing about and parsing documents until I have a solid framework, so I don't feel like my slightly less technical knowledge coming out of school has been a detriment. I am really thankful for my liberal arts education, I really think it is a great framework for education and while I might not suggest my specific school to everyone, I would 10000% suggest a liberal arts education to everyone who is looking at higher education.
TL;DR: I think there's a lot of problems with the way engineering programs are formatted and they are correlated with why there are a lot of shitty people in tech (I don't think it necessarily CAUSES it, but I don't think they help and I could see them making it worse), and I think prioritizing taking classes outside of engineering, specifically in the humanities is a way to improve that. There will be people who refuse to be open minded but I still think it will help a lot of people be better engineers and people and strengthen the field overall.
So it definitely is harder, and a lot of times I actually don't really market them very much directly (whoops!). If the interviewer asks me to talk about my strengths I will talk about them, but...
So it definitely is harder, and a lot of times I actually don't really market them very much directly (whoops!). If the interviewer asks me to talk about my strengths I will talk about them, but that's about the only time I directly talk about them. Otherwise, I usually show them indirectly.
I have been told a lot that I interview very well. This comes as feedback both from jobs that have hired me as well as jobs that haven't hired me when I follow up to see why I fell short (usually it'll be something along the lines of "he is very good at communicating and working with others but doesn't have quite enough experience in <insert tech>" but I'm also notorious for applying for jobs in tech I have no experience in). Almost all the skills I talked about in my last comment fall into one of two categories: communication or critical thinking. An interview is basically giving a conversational presentation where the subject is "Why you should hire me" and white boarding questions are basically an improvised presentation on material you should vaguely know. I would say that the way I talk and my body language is very confident but friendly, I don't use a lot of filler words even when I am taken off guard, I don't speak too fast or too slow. Most interviews have a standard set of questions about you as a person/developer that they all ask, and I have very practiced answers that I give. Not that I give word for word, but more I know the bullet points I want to hit inside and out so I can weave it into a very natural and conversational answer. The critical thinking skills I mostly show off when I am asked "do you have any questions for me?" from the interviewer. I find most people don't make great use of that opportunity. I spend a lot of time prior to my onsite thinking about that question. Do some research about the company, what are they in the news about, what are their competitors in the news for, what big things are happening in the field? Example: I work at a review company and was interviewing right as yelp was in the news for exploiting local businesses. I asked the manager I was interviewing with what he thought of the story and what guardrails <company> had in place or on the roadmap to avoid being in a similar situation. He said it was the first time someone had asked him about company ethics in an interview and he really liked that question because it showed I was ready to commit to making the company the best place possible. I make a point to talk to admin assistants/front desk people while I am at the company because (1) I think it says a lot about the morals of a company how they treat the non-engineers and (2) a lot of companies ask them how the interviewee treated them.
NOTE: Some of the specifics I gave are not great advice for getting hired. There will be companies that will be turned off by questions about ethics and morals in interviews I am sure. I ask those kinds of questions because it is important to me that I work at a company that treats all of its employees and its customers well. I acknowledge I am privileged enough to be financially stable enough to a point where I can risk losing an offer based on what questions I ask.
TL;DR: I don't typically convey soft skills directly by talking about them, I convey soft skills indirectly via my interview prep, by thinking outside of the typical "how to ace the engineering interview" box, and my communication skills while conversing with people within the company and while doing the whiteboard problems.
A lot of nerdy communities suffer from a lack of social skills since a lot of nerdy activities are more or less defined by not requiring social interaction.
A lot of nerdy communities suffer from a lack of social skills since a lot of nerdy activities are more or less defined by not requiring social interaction.
Author of the post here. I agree with you completely. This piece that I wrote was indeed a rant piece, rather than intending to be very calm and collected constructive criticism. I do stand by the...
Author of the post here. I agree with you completely. This piece that I wrote was indeed a rant piece, rather than intending to be very calm and collected constructive criticism. I do stand by the point, I think that typing speed is important in a developer's career and important for most people in IT to work on and is often overlooked as important with the concept that, "we don't spend all of our time writing code". Typing however as I went into in the article encompasses a lot more than just writing code, when you take into account the average daily activities of a developer.
It was snarky and rude, admittedly, and I appreciate the feedback.
I actually did tag it as such on my blog, but it was as a secondary tag. Apologies. I’ve updated the contact page to include my newly found tildes account: https://htmlpasta.com/contact/ So that...
I actually did tag it as such on my blog, but it was as a secondary tag. Apologies.
I think this well-intentioned advice that skips over the largest hurdle in programming generally: problem solving. I don't like admitting how much of the time I'm not typing at all because I am...
I think this well-intentioned advice that skips over the largest hurdle in programming generally: problem solving. I don't like admitting how much of the time I'm not typing at all because I am thinking through what I want to be doing with a specific package of content, or root cause analysis for a bug that is coming up. Or looking up (on DuckDuckGo, shoutout!) ways that other programmers asked and tried to answer similar questions as the ones I'm facing. Problem solving is far and away the skill I apply the most when I'm programming, moreso than typing even.
There is a danger when we focus too much on raw typing speed that we miss out on other, very important gains at the same time. One of the reasons my older colleagues stay relevant despite not necessarily knowing as much about programming as I do is they understand the data so much better than I do. They know what content is the most relevant to produce for our end users. They know it because that experience is very hard won. Institutional knowledge is a crucial component to any mature organization. Not every programmer is working on content from scratch. Many of us (maybe even most) are working with someone else's infrastructure and content.
If the point is limited to the simple observation that you'll improve your ability to interact with a computer by typing faster, there's really no argument to be had. But in this era, with our tendency to focus too much on one trait in lieu of others, we risk misidentifying the attributes that make someone successful, and that seems to be happening in this article too. I mean, at one point this author comes right out and says he thinks anyone who can't burst above 100+ wpm in their natural language is lazy. That's taking a simple point into territories that are much harder to defend.
I don't really think my typing speed is slow (mid 80s average, with bursts into 110pm range), but I wouldn't highlight that for too much. The most I could say for it in the author's support is that my comfort with my own typing speed leads me to see thorough documentation as less of a cost than it might seem to someone with a slower typing speed. That's not nothing, but it's also not everything.
As a relatively slow typist, averaging in the 60-70 range....I completely agree. Author even touches on this (that this is just one factor of many), but I would argue that of all the skills to...
As a relatively slow typist, averaging in the 60-70 range....I completely agree. Author even touches on this (that this is just one factor of many), but I would argue that of all the skills to spend time on improving, typing speed is probably the least important.
I would say the single most important skill is critical thinking, but a close second that is easier to work on is reading speed and comprehension. Sure, if you can type 120 WPM sustained you'll be 2x faster than me at writing. But if you only read at 200 WPM and 60% comprehension (supposedly average), I'll be almost 4x faster than you and be 20% less likely to need to re-read or mis-interpret the content.
Even with my (supposedly high) reading speed, I spend almost 50% or more of each work day reading. Log files, emails, chats, google results, and code review are all dramatically reading bound, not writing/interacting bound.
If I were in a hiring position, and two applicants were equally qualified, and one had exceptional typing skills and the other exceptional reading skills, I would pick the fast reader every time.
Code reading comprehension and ability to do that at fast rates and accurately envision how the code would work is definitely an immensely important skill in programming, I agree with you. Perhaps...
Code reading comprehension and ability to do that at fast rates and accurately envision how the code would work is definitely an immensely important skill in programming, I agree with you.
Perhaps I could’ve worded some of the gripes in a less abrasive way, for sure. I do stand by the reasoning though that strengthening this area of your ability shouldn’t be ignored as it is important, it’s just another one of those barriers between you and making the computer perform actions.
This may be a trivial observation, but it seems to me that code which can be generated consistently at 140 WPM is a likely product of ML/AI in the near future. If the inputs and requirements are...
This may be a trivial observation, but it seems to me that code which can be generated consistently at 140 WPM is a likely product of ML/AI in the near future.
If the inputs and requirements are so deterministic that there's no need of pauses for design and customization, why bother to have a human generate the code?
I don’t see why you would need ai/ml for that? Technically it’s possible to generate Software just by graphically designing what you want your tool to do, the underlying code can just be generated...
I don’t see why you would need ai/ml for that?
Technically it’s possible to generate Software just by graphically designing what you want your tool to do, the underlying code can just be generated then
A surprising amount of code can just be inferred as well. Writing a basic Java class, for example, I just set up the instance variable names and IntelliJ can automatically write generators,...
A surprising amount of code can just be inferred as well. Writing a basic Java class, for example, I just set up the instance variable names and IntelliJ can automatically write generators, getters, and setters by itself.
I've seen some of the products that claim to do that, and it's really not quite that simple. They presume the service requester has sufficient sophistication to understand the steps they want to...
I've seen some of the products that claim to do that, and it's really not quite that simple. They presume the service requester has sufficient sophistication to understand the steps they want to execute and the different UI paths those steps might take.
I'd expect well-trained AI/ML will eventually be able to take the verbal content of a marketing meeting and turn that into a product with little additional refinement ("now make it blue"...) needed.
I can't think as fast as I can type. And I can't type that fast to begin with (~80wpm as long as you don't throw a whole bunch of special characters at me). When I see a programming problem, I sit...
I can't think as fast as I can type. And I can't type that fast to begin with (~80wpm as long as you don't throw a whole bunch of special characters at me).
When I see a programming problem, I sit down and think "how on earth do I do this, what variables, what loops, how is it formatted, is there a logical order to put things in, what should I start with". And then I type. And perhaps if I typed faster I would be a bit faster. But I'm still going to need time to think about how this line I just wrote fits in with everything else.
Perhaps this is due to my programming inexperience, and a more experienced programmer would think faster. Idk. If I thought faster than I typed, then perhaps this would be an issue for me, but it isn't.
I feel I would speed myself up more by learning how to think logically (probably by programming more) than by learning how to type faster, which will probably just come over time anyway.
I think the title of the piece has a point, but that the arguments within it are poor. Whether you're someone who writes documents for work, types code, writes formulas, whether you're a...
I think the title of the piece has a point, but that the arguments within it are poor.
Whether you're someone who writes documents for work, types code, writes formulas, whether you're a mathematician or work in whatever profession: When you have to slow down your work because of writing/typing, you're often seriously impacting your train of thought and ability to work with complex problems within your mind.
This is analogous to having to stop to think when you're in the middle of saying something. You break trains of thought, you spend effort being in two places at once mentally, and you break flow.
Another less analogous example that illustrates a point: When you looked at a formula sheet in high school, but didn't have those formulas internalized, your ability to apply those formulas were greatly reduced. That's why wrote learning is important.
A somewhat similar thing is going on whenever your flow is interrupted by having to finish typing something. You suddenly have two separate tasks going on at once.
It's like a musician who can't focus on playing music well but playing it at all while sightreading: They're at their max speed so there's no residual capacity to excel.
The ability to singly focus on one thing is a skill that's grossly underrated. Especially when you're doing something that's mentally difficult, like working out complicated code.
Typing speed does make you a much more efficient coder, not because of speed, but because you can problem-solve more efficiently. It's about fluency in the (coding) language you're working in.
Speed is a skill/quality, not because you get more things done, but because you have the mental capacity to do things better.
Context switching is definitely a problem, but I would say is more impacted by muscle memory rather than speed. They go hand in hand, but speed is a byproduct of muscle memory. I suppose that's...
Context switching is definitely a problem, but I would say is more impacted by muscle memory rather than speed. They go hand in hand, but speed is a byproduct of muscle memory.
I suppose that's one reason I gravitate towards Python when given a choice...it has far less dependence on special characters that were barely touched on during my formative years of learning touch typing.
This is a great way to put it and was actually what I was trying to convey in the article, as I repeated a few times the concept “learning is by doing”, which I believe is especially true in...
Typing speed does make you a much more efficient coder, not because of speed, but because you can problem-solve more efficiently
This is a great way to put it and was actually what I was trying to convey in the article, as I repeated a few times the concept “learning is by doing”, which I believe is especially true in coding. I could’ve conveyed that in a more eloquent way, probably.
Isn't 100 words per minutes like crazy fast? Not crazy crazy, but like top 1%? When would you even think in 100 words per minute while programming? And if you cared about speed so much, wouldn't...
Isn't 100 words per minutes like crazy fast? Not crazy crazy, but like top 1%? When would you even think in 100 words per minute while programming? And if you cared about speed so much, wouldn't you use macros (or good old ctrl-v)?
Most importantly, can you read an article like that without immoderately trying to prove the author wrong if for no other reason than that he comes off as a dick and you don't want dicks to dictate quality standards?
EDIT: He's quoting this article by Jeff Atwood who types 84 WPS. Well fuck that whole "cringe at sub-100 WPM" bit, then.
I'd have agreed with you in the past, as I used to average 105 - 110 WPM. To my dismay, I've found that this isn't sustainable forever, and I'm at 80 on a good day now. Like any athletic...
I'd have agreed with you in the past, as I used to average 105 - 110 WPM. To my dismay, I've found that this isn't sustainable forever, and I'm at 80 on a good day now.
Like any athletic undertaking, bad ergonomics, cumulative trauma, arthritis, and aging take their toll. It's unwise, and inhumane, to pretend that only the fastest are worthy of regard.
The fastest typists, like courtroom stenographers and closed-captioners, use heavily modified typing devices and shorthand characters to attain 180 - 220 WPM on a sustainable basis.
If anything, pushing for constant maximum speed is another insidious way for extractive capitalism to force maximal productivity at individual expense. Why should it be necessary to go as fast as possible at all times, to compete even when no one is keeping score?
I guess you can pick it up as a sport but the guy who started the whole topic types at 84 WPS. Like, if it's fast enough for Jeff Atwood, it's fast enough for you. Everyone in this thread is...
I guess you can pick it up as a sport but the guy who started the whole topic types at 84 WPS. Like, if it's fast enough for Jeff Atwood, it's fast enough for you. Everyone in this thread is really talking about this bit of the article:
When I see someone who has been working with computers for a decade and can't surpass 100 WPM for even a short burst, I'll admit, it makes me cringe a little bit. It's just lazy, as Jeff Atwood put it.
Which is disproved by a link he posted in the first sentence.
I'm not saying that training typing isn't a super valuable skill. I consistently list it as one of the best individual skills to learn. It's probably reasonable to try and go for 100 WPM if you work as a programmer, it's very likely worth it. But the guy just "cringed" at someone below that mark and that's just like... dude, fuck you.
We're all talking about tone, not the content of the article because it's so fucking obnoxious.
Admittedly while my article is very ranty and partisan to the issue, I think the subject is difficult to ever write about without being at least somewhat divisive. Not an excuse of course for...
Gee, I wonder if it has anything to do with the way articles about the subject are written...
Admittedly while my article is very ranty and partisan to the issue, I think the subject is difficult to ever write about without being at least somewhat divisive. Not an excuse of course for being so divisive myself, past what would be “normal” given the discussion.
I do appreciate your commentary however and your defense of the 100 WPM mark. I absolutely believe that most developers have the ability to write much faster than they are and that it’d be helpful to them to learn to do so. I don’t think it’s a lack of aptitude or ability, I think mostly it’s a lack of not thinking it’s important and that’s the idea I was tackling.
The commentary here though has given some good food for thought on how to approach the discussion in future in a less abrasive manner.
I don’t disagree with you at all, I wrote it because it’s the truth I live in my day to day life as a developer. Perhaps I am an asshole. I also however, feel that it’s an important part of their...
But the guy just "cringed" at someone below that mark and that's just like... dude, fuck you.
I don’t disagree with you at all, I wrote it because it’s the truth I live in my day to day life as a developer. Perhaps I am an asshole. I also however, feel that it’s an important part of their career and to me, it’s an alien concept that after so many years you would still type at such a pace. Reasonable pace, mind you, not slow.
I guess the article is also a frustrated response to those that think that typing speed is not important at all for coding, which I think just ignores the tons of other ways in which typing better helps you be a better developer.
And yes, Jeff Atwood even, is kind of “average” at typing compared to everyone else who’s at his skill level of coding. His WPM is nothing to write home about. I wasn’t quoting him as a sort of authority though. I have massive respect for Jeff, he has accomplished amazing things regardless of his typing speed and I think he’s an interesting person.
Regardless, I appreciate your comments on the post and appreciate the “fuck you”, not sarcastically, to be clear! It gives me thought on how to better word my articles and ideas.
Very slow typers will definitely face problems, but requiring such a high wpm is just silly. I got 70wpm, and some people think I'm a fast typer. What's the use of typing fast if you cannot think...
Very slow typers will definitely face problems, but requiring such a high wpm is just silly. I got 70wpm, and some people think I'm a fast typer. What's the use of typing fast if you cannot think at the same speed?
Oh I make no claims about my programming skill; I may very well be a bad developer. I don’t feel that I am, but that could be confirmation bias :). But yes, there could be an element of that in...
Oh I make no claims about my programming skill; I may very well be a bad developer. I don’t feel that I am, but that could be confirmation bias :). But yes, there could be an element of that in the tone on some self reflection, for sure. Perhaps worth reflecting on.
This is the sort of completely pants on head retarded garbage that gave us lines of code as a job performance metric. And the 'thought experiment' portion was conspiracy theory levels of...
This is the sort of completely pants on head retarded garbage that gave us lines of code as a job performance metric. And the 'thought experiment' portion was conspiracy theory levels of misleading.
I teach, assess, and research code quality (among many other things in compsci and eng education). You will be a better programmer if you slow. the. fuck. down. 100 words per minute? You shouldn't be writing more than one line per minute, and preferably much less than that.
If you want to learn to type faster, power to you, but if you're even a little bit smart you'll get more use out of it writing reports and emails than you get out of programming.
As I felt I was quite clear on in the article, the act of writing code itself is just a small part of why typing fast is important but it’s the other parts around coding that also involve typing...
As I felt I was quite clear on in the article, the act of writing code itself is just a small part of why typing fast is important but it’s the other parts around coding that also involve typing that are also relevant and important. Writing code involves a lot of hitting keys other than just inputting the code into an editor, I tried to be very clear on that.
Could you give advice as to which part of this was unclear and how I could improve? Would be very appreciative.
In my experience, typing speed is almost never the limiting factor when doing technical work even though I don't often type much faster than 60 wpm. Increases in efficiency are much more likely to...
In my experience, typing speed is almost never the limiting factor when doing technical work even though I don't often type much faster than 60 wpm.
Increases in efficiency are much more likely to come from learning keyboard shortcuts and taking advantage of autocomplete but more generally by systematizing and/or automating your approach to things that you need to do repeatedly rather than squeezing out a bit more speed from your fingers.
On average over an entire day, maybe - but typing whilst programming is bursty. You might spend ten minutes thinking about the implementation of some component, then need to type several lines of...
You shouldn't be writing more than one line per minute, and preferably much less than that.
On average over an entire day, maybe - but typing whilst programming is bursty. You might spend ten minutes thinking about the implementation of some component, then need to type several lines of boilerplate at once.
Tangential to the post: sadly software engineering, along with other engineering disciplines, has a huge number of judgmental, rude, mean people employed in the profession. People who gaslight you for your (perceived) lack of skills, question your decisions snidely, or look down on you because they feel superior. These people are a stain on the industry.
I was one of these people for a while too. It took me a long time to embrace empathetic, considerate development—from caring about the end user, to being constructive and positive in code reviews. I don't entirely know how you solve the problem whether that's classes in being personable/caring at university, or just instilling positivity as part of a corporate style guide.
Regardless, there should be no space for such negativity or hurtful commentary towards others who are trying to climb the intellectual ladder. Give them a hand up, don't give the ladder sharp nails.
As a short aside. I want to shout out @Deimos who has made it easy for less experienced devs to contribute to Tildes. For me, even though I made some silly mistakes in my first PR, it was still welcomed. Corrections were made and explained and my contribution - albeit small - was encouraged. As a result, I learnt something and feel encouraged to continue to improve. I have unfortunately encountered the other approach. Unsurprisingly it has the opposite affect. It’s easy to forget there’s someone on the other end of a review.
Do you think this is a problem that's particularly serious in software engineering, or in IT in general, or in engineering in general?
I hope I have a good perspective to add to for both you and @ThatFanficGuy and @emdash.
I graduated 4 years ago with dual Bachelors of Arts in Mathematics and Computer Science from a small liberal arts school. A big part of liberal arts education is taking courses outside of your selected field. In order to graduate I had to take a lot of courses outside of STEM. I took a class on Theatre set design, 4 or 5 different religion classes, an English course, a Spanish course, a chemistry course, and another course that I know exactly what building I walked into on campus but I cannot for the life of me remember what it was this early in the AM. I would say the courses outside of my major are what make me a strong engineer and stand out more than anything I took within my degree. Since there is a focus on taking courses outside your major, that obviously means I took fewer courses than a traditional engineering program. There's only so many hours in a semester. It definitely made me slightly weaker in terms of programming. I don't know all the ins and outs of Linux or a complier in the same way some of my coworkers do. That said, I have a lot of strengths that they don't have that I learned in other courses. I am a lot better and communicating and working with the non-technical/non-engineers that come to our team in need of help, I am a lot better at writing clear, cohesive, useful documentation than a lot of others, I am better at problem solving, I am a lot better at seeing things from the user's perspective rather than just as purely an engineering problem to be solved. I give most of my team's presentations because I spent A LOT of time in college giving 15+ minute presentations on the relationships between cultures/historical events and religious texts and so I am very comfortable making longer presentations and delivering them. I spend more time thinking about UI and ethics than most my peers. I also have a really easy time learning and picking up new tech/projects because I'm really use to jumping into a subject I know nothing about and parsing documents until I have a solid framework, so I don't feel like my slightly less technical knowledge coming out of school has been a detriment. I am really thankful for my liberal arts education, I really think it is a great framework for education and while I might not suggest my specific school to everyone, I would 10000% suggest a liberal arts education to everyone who is looking at higher education.
TL;DR: I think there's a lot of problems with the way engineering programs are formatted and they are correlated with why there are a lot of shitty people in tech (I don't think it necessarily CAUSES it, but I don't think they help and I could see them making it worse), and I think prioritizing taking classes outside of engineering, specifically in the humanities is a way to improve that. There will be people who refuse to be open minded but I still think it will help a lot of people be better engineers and people and strengthen the field overall.
So it definitely is harder, and a lot of times I actually don't really market them very much directly (whoops!). If the interviewer asks me to talk about my strengths I will talk about them, but that's about the only time I directly talk about them. Otherwise, I usually show them indirectly.
I have been told a lot that I interview very well. This comes as feedback both from jobs that have hired me as well as jobs that haven't hired me when I follow up to see why I fell short (usually it'll be something along the lines of "he is very good at communicating and working with others but doesn't have quite enough experience in <insert tech>" but I'm also notorious for applying for jobs in tech I have no experience in). Almost all the skills I talked about in my last comment fall into one of two categories: communication or critical thinking. An interview is basically giving a conversational presentation where the subject is "Why you should hire me" and white boarding questions are basically an improvised presentation on material you should vaguely know. I would say that the way I talk and my body language is very confident but friendly, I don't use a lot of filler words even when I am taken off guard, I don't speak too fast or too slow. Most interviews have a standard set of questions about you as a person/developer that they all ask, and I have very practiced answers that I give. Not that I give word for word, but more I know the bullet points I want to hit inside and out so I can weave it into a very natural and conversational answer. The critical thinking skills I mostly show off when I am asked "do you have any questions for me?" from the interviewer. I find most people don't make great use of that opportunity. I spend a lot of time prior to my onsite thinking about that question. Do some research about the company, what are they in the news about, what are their competitors in the news for, what big things are happening in the field? Example: I work at a review company and was interviewing right as yelp was in the news for exploiting local businesses. I asked the manager I was interviewing with what he thought of the story and what guardrails <company> had in place or on the roadmap to avoid being in a similar situation. He said it was the first time someone had asked him about company ethics in an interview and he really liked that question because it showed I was ready to commit to making the company the best place possible. I make a point to talk to admin assistants/front desk people while I am at the company because (1) I think it says a lot about the morals of a company how they treat the non-engineers and (2) a lot of companies ask them how the interviewee treated them.
NOTE: Some of the specifics I gave are not great advice for getting hired. There will be companies that will be turned off by questions about ethics and morals in interviews I am sure. I ask those kinds of questions because it is important to me that I work at a company that treats all of its employees and its customers well. I acknowledge I am privileged enough to be financially stable enough to a point where I can risk losing an offer based on what questions I ask.
TL;DR: I don't typically convey soft skills directly by talking about them, I convey soft skills indirectly via my interview prep, by thinking outside of the typical "how to ace the engineering interview" box, and my communication skills while conversing with people within the company and while doing the whiteboard problems.
A lot of nerdy communities suffer from a lack of social skills since a lot of nerdy activities are more or less defined by not requiring social interaction.
Author of the post here. I agree with you completely. This piece that I wrote was indeed a rant piece, rather than intending to be very calm and collected constructive criticism. I do stand by the point, I think that typing speed is important in a developer's career and important for most people in IT to work on and is often overlooked as important with the concept that, "we don't spend all of our time writing code". Typing however as I went into in the article encompasses a lot more than just writing code, when you take into account the average daily activities of a developer.
It was snarky and rude, admittedly, and I appreciate the feedback.
Proof? AND if so why didn't they label this accordingly (as an opinion/rant piece)? Would have saved us a headache.
I actually did tag it as such on my blog, but it was as a secondary tag. Apologies.
I’ve updated the contact page to include my newly found tildes account:
https://htmlpasta.com/contact/
So that should be proof. Loving all of the discussions happening on here, it has been very constructive reading.
I think this well-intentioned advice that skips over the largest hurdle in programming generally: problem solving. I don't like admitting how much of the time I'm not typing at all because I am thinking through what I want to be doing with a specific package of content, or root cause analysis for a bug that is coming up. Or looking up (on DuckDuckGo, shoutout!) ways that other programmers asked and tried to answer similar questions as the ones I'm facing. Problem solving is far and away the skill I apply the most when I'm programming, moreso than typing even.
There is a danger when we focus too much on raw typing speed that we miss out on other, very important gains at the same time. One of the reasons my older colleagues stay relevant despite not necessarily knowing as much about programming as I do is they understand the data so much better than I do. They know what content is the most relevant to produce for our end users. They know it because that experience is very hard won. Institutional knowledge is a crucial component to any mature organization. Not every programmer is working on content from scratch. Many of us (maybe even most) are working with someone else's infrastructure and content.
If the point is limited to the simple observation that you'll improve your ability to interact with a computer by typing faster, there's really no argument to be had. But in this era, with our tendency to focus too much on one trait in lieu of others, we risk misidentifying the attributes that make someone successful, and that seems to be happening in this article too. I mean, at one point this author comes right out and says he thinks anyone who can't burst above 100+ wpm in their natural language is lazy. That's taking a simple point into territories that are much harder to defend.
I don't really think my typing speed is slow (mid 80s average, with bursts into 110pm range), but I wouldn't highlight that for too much. The most I could say for it in the author's support is that my comfort with my own typing speed leads me to see thorough documentation as less of a cost than it might seem to someone with a slower typing speed. That's not nothing, but it's also not everything.
As a relatively slow typist, averaging in the 60-70 range....I completely agree. Author even touches on this (that this is just one factor of many), but I would argue that of all the skills to spend time on improving, typing speed is probably the least important.
I would say the single most important skill is critical thinking, but a close second that is easier to work on is reading speed and comprehension. Sure, if you can type 120 WPM sustained you'll be 2x faster than me at writing. But if you only read at 200 WPM and 60% comprehension (supposedly average), I'll be almost 4x faster than you and be 20% less likely to need to re-read or mis-interpret the content.
Claims backed by results from this test, the first result I got for "reading WPM test". I scored 761 WPM with 82% comprehension. Not positive on the accuracy of their claims, but they do support my gut feeling.
Even with my (supposedly high) reading speed, I spend almost 50% or more of each work day reading. Log files, emails, chats, google results, and code review are all dramatically reading bound, not writing/interacting bound.
If I were in a hiring position, and two applicants were equally qualified, and one had exceptional typing skills and the other exceptional reading skills, I would pick the fast reader every time.
Code reading comprehension and ability to do that at fast rates and accurately envision how the code would work is definitely an immensely important skill in programming, I agree with you.
Perhaps I could’ve worded some of the gripes in a less abrasive way, for sure. I do stand by the reasoning though that strengthening this area of your ability shouldn’t be ignored as it is important, it’s just another one of those barriers between you and making the computer perform actions.
I appreciate the thought out response, though.
This may be a trivial observation, but it seems to me that code which can be generated consistently at 140 WPM is a likely product of ML/AI in the near future.
If the inputs and requirements are so deterministic that there's no need of pauses for design and customization, why bother to have a human generate the code?
I don’t see why you would need ai/ml for that?
Technically it’s possible to generate Software just by graphically designing what you want your tool to do, the underlying code can just be generated then
A surprising amount of code can just be inferred as well. Writing a basic Java class, for example, I just set up the instance variable names and IntelliJ can automatically write generators, getters, and setters by itself.
I've seen some of the products that claim to do that, and it's really not quite that simple. They presume the service requester has sufficient sophistication to understand the steps they want to execute and the different UI paths those steps might take.
I'd expect well-trained AI/ML will eventually be able to take the verbal content of a marketing meeting and turn that into a product with little additional refinement ("now make it blue"...) needed.
I see, you we’re talking about the more advanced version, that’s true. I was talking about the stuff that Akir mentioned
I can't think as fast as I can type. And I can't type that fast to begin with (~80wpm as long as you don't throw a whole bunch of special characters at me).
When I see a programming problem, I sit down and think "how on earth do I do this, what variables, what loops, how is it formatted, is there a logical order to put things in, what should I start with". And then I type. And perhaps if I typed faster I would be a bit faster. But I'm still going to need time to think about how this line I just wrote fits in with everything else.
Perhaps this is due to my programming inexperience, and a more experienced programmer would think faster. Idk. If I thought faster than I typed, then perhaps this would be an issue for me, but it isn't.
I feel I would speed myself up more by learning how to think logically (probably by programming more) than by learning how to type faster, which will probably just come over time anyway.
I think the title of the piece has a point, but that the arguments within it are poor.
Whether you're someone who writes documents for work, types code, writes formulas, whether you're a mathematician or work in whatever profession: When you have to slow down your work because of writing/typing, you're often seriously impacting your train of thought and ability to work with complex problems within your mind.
This is analogous to having to stop to think when you're in the middle of saying something. You break trains of thought, you spend effort being in two places at once mentally, and you break flow.
Another less analogous example that illustrates a point: When you looked at a formula sheet in high school, but didn't have those formulas internalized, your ability to apply those formulas were greatly reduced. That's why wrote learning is important.
A somewhat similar thing is going on whenever your flow is interrupted by having to finish typing something. You suddenly have two separate tasks going on at once.
It's like a musician who can't focus on playing music well but playing it at all while sightreading: They're at their max speed so there's no residual capacity to excel.
The ability to singly focus on one thing is a skill that's grossly underrated. Especially when you're doing something that's mentally difficult, like working out complicated code.
Typing speed does make you a much more efficient coder, not because of speed, but because you can problem-solve more efficiently. It's about fluency in the (coding) language you're working in.
Speed is a skill/quality, not because you get more things done, but because you have the mental capacity to do things better.
Context switching is definitely a problem, but I would say is more impacted by muscle memory rather than speed. They go hand in hand, but speed is a byproduct of muscle memory.
I suppose that's one reason I gravitate towards Python when given a choice...it has far less dependence on special characters that were barely touched on during my formative years of learning touch typing.
This is a great way to put it and was actually what I was trying to convey in the article, as I repeated a few times the concept “learning is by doing”, which I believe is especially true in coding. I could’ve conveyed that in a more eloquent way, probably.
Isn't 100 words per minutes like crazy fast? Not crazy crazy, but like top 1%? When would you even think in 100 words per minute while programming? And if you cared about speed so much, wouldn't you use macros (or good old ctrl-v)?
Most importantly, can you read an article like that without immoderately trying to prove the author wrong if for no other reason than that he comes off as a dick and you don't want dicks to dictate quality standards?
EDIT: He's quoting this article by Jeff Atwood who types 84 WPS. Well fuck that whole "cringe at sub-100 WPM" bit, then.
I'd have agreed with you in the past, as I used to average 105 - 110 WPM. To my dismay, I've found that this isn't sustainable forever, and I'm at 80 on a good day now.
Like any athletic undertaking, bad ergonomics, cumulative trauma, arthritis, and aging take their toll. It's unwise, and inhumane, to pretend that only the fastest are worthy of regard.
The fastest typists, like courtroom stenographers and closed-captioners, use heavily modified typing devices and shorthand characters to attain 180 - 220 WPM on a sustainable basis.
If anything, pushing for constant maximum speed is another insidious way for extractive capitalism to force maximal productivity at individual expense. Why should it be necessary to go as fast as possible at all times, to compete even when no one is keeping score?
I guess you can pick it up as a sport but the guy who started the whole topic types at 84 WPS. Like, if it's fast enough for Jeff Atwood, it's fast enough for you. Everyone in this thread is really talking about this bit of the article:
Which is disproved by a link he posted in the first sentence.
I'm not saying that training typing isn't a super valuable skill. I consistently list it as one of the best individual skills to learn. It's probably reasonable to try and go for 100 WPM if you work as a programmer, it's very likely worth it. But the guy just "cringed" at someone below that mark and that's just like... dude, fuck you.
We're all talking about tone, not the content of the article because it's so fucking obnoxious.
Admittedly while my article is very ranty and partisan to the issue, I think the subject is difficult to ever write about without being at least somewhat divisive. Not an excuse of course for being so divisive myself, past what would be “normal” given the discussion.
I do appreciate your commentary however and your defense of the 100 WPM mark. I absolutely believe that most developers have the ability to write much faster than they are and that it’d be helpful to them to learn to do so. I don’t think it’s a lack of aptitude or ability, I think mostly it’s a lack of not thinking it’s important and that’s the idea I was tackling.
The commentary here though has given some good food for thought on how to approach the discussion in future in a less abrasive manner.
I don’t disagree with you at all, I wrote it because it’s the truth I live in my day to day life as a developer. Perhaps I am an asshole. I also however, feel that it’s an important part of their career and to me, it’s an alien concept that after so many years you would still type at such a pace. Reasonable pace, mind you, not slow.
I guess the article is also a frustrated response to those that think that typing speed is not important at all for coding, which I think just ignores the tons of other ways in which typing better helps you be a better developer.
And yes, Jeff Atwood even, is kind of “average” at typing compared to everyone else who’s at his skill level of coding. His WPM is nothing to write home about. I wasn’t quoting him as a sort of authority though. I have massive respect for Jeff, he has accomplished amazing things regardless of his typing speed and I think he’s an interesting person.
Regardless, I appreciate your comments on the post and appreciate the “fuck you”, not sarcastically, to be clear! It gives me thought on how to better word my articles and ideas.
Very slow typers will definitely face problems, but requiring such a high wpm is just silly. I got 70wpm, and some people think I'm a fast typer. What's the use of typing fast if you cannot think at the same speed?
Oh I make no claims about my programming skill; I may very well be a bad developer. I don’t feel that I am, but that could be confirmation bias :). But yes, there could be an element of that in the tone on some self reflection, for sure. Perhaps worth reflecting on.
Oh no it’s all received in good faith, don’t worry about it. There was no need to delete the comment!
This is the sort of completely pants on head retarded garbage that gave us lines of code as a job performance metric. And the 'thought experiment' portion was conspiracy theory levels of misleading.
I teach, assess, and research code quality (among many other things in compsci and eng education). You will be a better programmer if you slow. the. fuck. down. 100 words per minute? You shouldn't be writing more than one line per minute, and preferably much less than that.
If you want to learn to type faster, power to you, but if you're even a little bit smart you'll get more use out of it writing reports and emails than you get out of programming.
As I felt I was quite clear on in the article, the act of writing code itself is just a small part of why typing fast is important but it’s the other parts around coding that also involve typing that are also relevant and important. Writing code involves a lot of hitting keys other than just inputting the code into an editor, I tried to be very clear on that.
Could you give advice as to which part of this was unclear and how I could improve? Would be very appreciative.
In my experience, typing speed is almost never the limiting factor when doing technical work even though I don't often type much faster than 60 wpm.
Increases in efficiency are much more likely to come from learning keyboard shortcuts and taking advantage of autocomplete but more generally by systematizing and/or automating your approach to things that you need to do repeatedly rather than squeezing out a bit more speed from your fingers.
On average over an entire day, maybe - but typing whilst programming is bursty. You might spend ten minutes thinking about the implementation of some component, then need to type several lines of boilerplate at once.