I guess it's like saying the most important traits of a golfer are patience and focus. Sure, if you're missing those, you'll toxically spiral when you don't perform, but are those the "most important skills" in golf? Nope, I'd say those would be the technical skills that let you make the shot.
I think the perspective of this is assuming that the technical skill is there. You're totally right that the difference between a prime Tiger Woods and the field is definitely talent related.
But when there's a lot bigger population who all have a similar level of technical skill and that's not the limiter, I can agree these things are some of the important differentiators.
I would argue that social skills are very valuable. At least, in the projects where I ended up, there are a lot of people writing code of debatable quality in a big, messy codebase. Asking around and communicating stuff helps you understand what's going on, and what to touch and where to stay away.
> So many things have to go right just to get a software program to compile. That’s why attention to detail is so important...
Even the sloppiest coders who work with no attention to detail still compile their code with ease. I get the author's larger point about attention to detail but I don't think compilation is an effective example to illustrate that point.
You've been lucky, then. At half the companies I've worked for, there's that One Person who regularly breaks the build for everybody by checking in code that doesn't even compile.
This is 98% of why I push for continuous integration. I don't care about unit tests for their own sake, and I don't bother for my personal projects. I only want CI on a team so that when it turns red, there's an unbiased third-party building the code, and I can simply point to it and "the build is broken, please fix". Otherwise, I have to have the same conversation every week, and it always begins with "Oh, I don't think I caused that!"
I've worked with people who struggled to get code to merely compile--and not just in CompSci 101 back in university where this was at least 80% of the programming students. In actual companies where they were hired as software engineers. Granted, they don't last long.
Agreed. I generally see a lack of attention to detail with regard to things like linting, unit tests, and documentation. Our CI builds fail way too often due to the first two items, which can be easily done via a single build target on a developer's machine.
I agree with the author on patience, but I wonder if you can become a software developer without it. Sure some people will have more than others, but learning how to make code work is a terrible, terrible process and I’m not sure you can go through it without massive amounts of patience.
I have a side job as an examiner for Danish CS students, and a noticible difference between first years and final project students is how they tolerate the frustration of having code not work. If you can’t sit through hours of not knowing why something just doesn’t work, you probably find a different field.
I think you can have different types of patience. Patience with getting something to work could be very different from the patience to build something correctly, which could be different from the patience to deal with people...
But I agree - you probably won't become a dev without having or learning some degree of patience.
> Sure some people will have more than others, but learning how to make code work is a terrible, terrible process and I’m not sure you can go through it without massive amounts of patience.
I think this is more about being diligent than being patient.
There are plenty (too many?) devs who will diligently try and figure out something but that have no patience when dealing with others.
It does require a certain level of patience. Then again, I've known a fair share of developers who will do just about anything to "make it work" even if it means copy/pasting snippets they don't understand.
"Attention to Detail" is my major weak point. I don't have it in coding. Give my a philosophical essay, a political discussion or an academic paper and I'll drown you in details, implications and references. Those come intuitively to me.
Writing codes is completely different. I have to practice everything what others seem to do intuitively. I need checklists. I need to take notes. I need to review my task and codes several times. And still, I overlook the obvious and never spot the easiest implementation (even for trivial tasks like checking for empty Strings). All while it takes me a great deal of discipline to take care of the level of detail that is required.
If someone here has/had the same problem, I'd like to hear their solutions.
Just out of curiosity, is you background in web development and/or the C family of languages (i.e. C, C++, C#)?
I mention these because they rely heavily on object-oriented and/or imperative programming paradigms. With C and C++, I still struggle often with striking a good balance between "writing a short solution that works well" and "writing code which is a joy for others to read". The former often relies on my technical knowledge and produces code that can be obscure to other readers, the latter often requires MUCH more concentration and attention to detail when writing.
However, I have recently started experimenting with declarative and functional Programming. Coming from an imperative background has made "relearning" how to program quite difficult for me, but I've just started to see the "elegance" in higher level functional languages, such as OcaML and Haskell. Of course, functional languages are often MUCH better suited to different problems than OOP languages, but combining filters, reductions, maps and folds seems to activate the parts of my brain that are much more closely associated with the "classical logic" side of programming. I think you should check it out if you haven't already.
I suffer from similar issues. Something that really works against me in the standard coding interviews. Some ways I try to mitigate some of those issues at work are:
1) Peer/senior code reviews. I try and get code reviews done by other folks. This helps with identifying something easy that I may be missing. Usually, once I already have a solution to a problem, I find it hard to revisit it without that solution overwhelming my approach, unless a bit of time has passed. Getting some fresh eyes to look at it helps. Also, explaining the solution to someone else often helps me identify issues with my solution during the process of explaining it to someone else itsel.
2) Practice and experience. I think for the most part intuition is simply the result of experience and practice.
3) Learning different programming paradigms. Something that has helped me more than anything else I think is learning programming languages that cover different paradigms. I’ve never coded anything useful in Haskell, but just the process of solving basic programming problems in Haskell, with its strong functional approach, helps me identify issues with the proceduaral/OOP code which I do write to solve useful problems. I think it allows me to approach each problem from multiple perspectives so even if I don’t have certain Haskell features available to me, it makes it easier to recognize that this may be an issue I need to address in my OOP code (for example, the Haskell compiler when pattern matching requires all possibilities to be addressed. Awareness of this fact means that anytime I’m writing conditionals checking the input I’m much more aware of the fact that I need to also handle the else condition, something that most non-functional programming languages don’t hsually require in their conditional constructs).
4) Related to #3m opting for better solutions wherever possible. I always try and opt for expressions over statements. I try to avoid state change as much as possible. I try and minimize side effects in functions, and try to constrain them in specific areas of code, etc.
5) Formal CS study. I don’t have a CS background, but studying formal CS in my free time has helped a lot. Getting better at data structures, algorithms, formal verification, etc, has helped develop my intuitions even if I don’t sctually use those data structures and formal verification methods in practice.
I can speak to this issue as someone who comes from a formal background of philosophy and literature, but whose work involves a lot of programming (both reading and writing code) at this point.
Foremost: practice. If you can read and write essays at a college level you've been practicing the craft for (likely) years. Most educated people in the US start engaging with letterforms as soon as kindergarten (!), and no later than 1st grade if not preschool. Contrarily, we don't start so early with the rules of logic nor programming constructs. Most folks don't start programming until much later, and even those who are precocious in this regard usually don't begin using "real" languages (in other words, not stuff like lego robotics or scratch) until they are ~13 or so (of course, there are plenty of exceptions). As with most skills, practice is invaluable.
On a conceptual level, I found that making the jump from asking myself what does this code do to what does this code mean majorly beneficial. It may seem like a minuscule or pedantic semantic point, but it actually makes a world of difference. Just like essays, programs are expressing—they are saying something. If you shift from approaching programming from a goal oriented perspective to a communications perspective your code will probably improve immensely. I think this is the reason guys like Donald Knuth stress code readability and literate programming so heavily—at the end of the day, that's what's really important: communicating some idea—just like we do in plain old english. We simply have a broader audience (the latter part of which is very picky about what it understands). The notion of a proposition in logic doesn't do, it means. Programs are essentially a set of propositions which just so happen to have the side effect that they can make a device (a computer) do something when it interprets them. Just as linguistic commands ("go to the store") are "pure" and free of side effects in and of themselves—they only have effects under human interpretation.
On a somewhat related note, I find stepping away from programming languages and starting with pen and paper is great. I think people tend to let programming languages get in the way of the real nature of what it is they're doing, which is solving problems in a structured manner, using mathematics and logic (algorithms and data structures). You don't need a programming language to do this, it's only a vehicle to express your solution. Just as you'd often start writing a formal paper by exploring your ideas in an outline or notes, or a couple of first drafts in which you hash things out, you can start "programming" by sketching ideas for solutions and better comprehending the problem at hand. This will ultimately help you write better code. I think a lot of self-taught devs, such as myself, miss this part early on as our entry point into the discipline is often through the languages and tends to kind of remain at the level of the languages we like unless we dig deeper into the underlying formalisms driving them. Too often people just go along with their first-pass understanding of a problem and begin reaching for the libraries, language constructs, etc. that they think they need. Someone with formal training, contrarily, has professors that can help them recognize the concepts behind the languages and connect up and distinguish the notion of a language as a mode of expression and programmatic problem solving as a practice irrespective of the selected language.
I have always strongly believed that "Tech skills make you good. Other skills make you better."
OP brings up a lot of good points (who could argue with these), but overlooks my #1 fundamental: If you can't write good code, not much else matters.
I know lots of programmers who have mastered the technical skills but are weak at the other things, so no one would ever mistake them for "senior", no matter how good their code is.
But I know many more "I.T. people" who are good at the "soft stuff" (analysis, design, product ownership, people management, agile, etc.) but can't code. I don't want to sound snarky, but these people are a dime a dozen. They often have great attention to detail and patience, but would you really entrust them to build your software?
Learn how to build software first. Be able to do that well before adding the soft skills.
That's the most important software dev skill needed. And it is most definitely "technical".
> If you can't write good code, not much else matters.
Can't stress this enough and I frankly don't understand all these articles claiming otherwise, when even the most minimal reflection would clear things up in a jiffy:
Take a skilled trapeze artist who has great attention to detail (I hope) and is patient (I hope) but cannot code.
Alternatively take a brilliant software developer who is slightly sloppy and not very patient.
Which one do you want writing your software?
Of course, that's accepting that these are important skills/attributes. I don't actually agree they are. See
We’ve already seen a fairly consistent trend - high performing / good companies allow failure but do not tolerate incompetence. The bar for competency in software as an industry and profession is all over the place. Most white collar professions have some forms of basic competency that’s somewhat objective where interviews are almost entirely about the soft parts as a result. Meanwhile, most of us are grinding leetcode and Hackerrank...
"Most important"? My mother is a patient and detail-oriented person, but I wouldn't hire her as a software dev.
To take a less extreme example, depending on the role I'd still rather hire someone who was occasionally impatient and didn't always write tests but knew how to code really well vs. a fresh grad who's always cheery and polishes the hell out of their work but takes a lot longer and produces meandering code.
If your mother is not a programmer, then (following the logic of the article) being a patient and detail-oriented person doesn't make someone automagically a programmer.
I would gladly hire her as a software dev over many of my former coworkers who were actual software devs.
It's quite possible to teach a conscientious person to write programs. I haven't figured out how to teach a person who writes programs to be conscientious.
I disagree, those are virtues one needs just to become a programmer. The only skill that matters in the end is velocity; these days you are required to deliver a 99.999% solution that solves some "unsolvable" computer science problem in a practical way within 3 months. Whatever helps you to get there is what you need to acquire, the rest is useless. This article seemed to me like a story from a developer that is just factually leaving being junior in practice (not in title) and observing there is a bit more complex world out there... I hope that person doesn't end up in management, enforcing their tunnel vision on everybody underneath, capping their capabilities.
People like you are the reason people like me are QA/SETs. Your velocity, in my view, is some slapdash worked-15-hour-days-because-they-thought-they-could nonsense that is more likely to crumble under load and/or the first edge case that pops to mind. The only one capping their capabilities here is you mate.
Also, knowing what to build helps a lot too. Many of the most successful companies and projects didn't come about just because there was a good developer/programmer involved, but because they identified a market with interest in it and built what said market wanted/needed.
A lot of people will just build stuff they find interesting/fun to build, but no one will care. What they will care about is whether it solves their problems, and they'll often go for a hacky, poorly done solution that does if need be.
Agreed; the single most important characteristic of an effective performer is Conscientiousness. Working at a task, measuring the result against a standard, working some more, until its actually really done.
The absence of this causes havok: a task thought done will turn out not-done at the deadline and become an emergency. A feature not measured against all the requirements will fail in test or worse! in the field and cause customer angst and extra cost to everybody.
I pretty much agree with the author.
I'm not a developer but I worked with many developers in the last 6 years.
Some of them were great and some were not so friendly.
-Respect for others
- Being friendly
- Give good energy to the people around you in the office
- Learn how to work in a team
Those are the things that when a good developer has, he becomes a game-changing part in a startup
While the traits mentioned in the article are useful (patience and attention to detail), these are traits that are selected against in most work environments. Writing software "The Right Way" TM takes time and time is usually something most engineers don't have in abundance.
No, I completely disagree. The most important skills, after being a competent developer, are being able to communicate and get along with our team.
It took me years to understand this but without being able to work with your team you will not e able to create great software.
It's possible to create a product that's not technically beautiful but it meets a real need in society. Ultimately we create software to meet a need. Once we understand the need we can go back and refactor it. But if we can't communicate and get along with our team then the chances of creating a good product are low.
The challenge of details is best solved via rigorous definition of “done” (i.e. acceptance criteria). If you don’t have consensus for that, there are a million ways someone else can re-define the problem and thus expose “incorrect details”. Many orgs delay this consensus, making for plenty of post code review work, but I don’t think that’s necessary bad so long as you don’t let PR comments hurt your ego.
To be honest, after I started in software development 10 years ago, the most important skill is (good) communication. If you can't understand your stakeholders or express concerns the prettiest code won't help you. Obviously it will help, but only after figuring out the former.
Communication is by far THE biggest issue in many projects. Especially with geeky introverty software dev types. Heck, my fiancee is a doctor and the amount of crap that happens in hospital just because people (other doctors/nurses/patients) don't communicate clearly, make tons of incorrect assumptions etc. is astonishing (and has direct consequence in quality and quantity of health care provided).
Both hard and soft skills are important. When the subject group are above a certain level of hard skills, you can identify real seniority and leadership capabilities by looking into soft skills.
same thoughts here. I mean i appreciate the article and write up. My big skill is openness, communication, honesty. I have worked with many brilliant nerds who cant stay focused and literally contribute jack shit to major projects. They probably make the most $$ too.
I dont care how good your program or app is. If you cant talk like a normal person, accept criticism, negotiate etc. You are going to suck. The best co-workers i have are able to combine both the CS tech knowledge with other skills like good estimation, honest and open communication, clear planning and execution etc.
You can just tell in my opinion. Start workign with someone on a project for an hour and you can tell if they are a nerd without focus who spends weeks doing useless shit, or someone who will seriously contribute to your team and help get shit done.
[+] [-] sammnaser|7 years ago|reply
[+] [-] mgoblu3|7 years ago|reply
But when there's a lot bigger population who all have a similar level of technical skill and that's not the limiter, I can agree these things are some of the important differentiators.
[+] [-] alexandercrohde|7 years ago|reply
Attention to Detail and Patience are key, often unsung, developer traits
[+] [-] hcarvalhoalves|7 years ago|reply
[+] [-] meuk|7 years ago|reply
[+] [-] apercu|7 years ago|reply
[+] [-] asaph|7 years ago|reply
Even the sloppiest coders who work with no attention to detail still compile their code with ease. I get the author's larger point about attention to detail but I don't think compilation is an effective example to illustrate that point.
[+] [-] ken|7 years ago|reply
This is 98% of why I push for continuous integration. I don't care about unit tests for their own sake, and I don't bother for my personal projects. I only want CI on a team so that when it turns red, there's an unbiased third-party building the code, and I can simply point to it and "the build is broken, please fix". Otherwise, I have to have the same conversation every week, and it always begins with "Oh, I don't think I caused that!"
[+] [-] ryandrake|7 years ago|reply
[+] [-] bmj|7 years ago|reply
[+] [-] yread|7 years ago|reply
[+] [-] sys_64738|7 years ago|reply
[+] [-] jaabe|7 years ago|reply
I have a side job as an examiner for Danish CS students, and a noticible difference between first years and final project students is how they tolerate the frustration of having code not work. If you can’t sit through hours of not knowing why something just doesn’t work, you probably find a different field.
[+] [-] swsieber|7 years ago|reply
But I agree - you probably won't become a dev without having or learning some degree of patience.
[+] [-] JustSomeNobody|7 years ago|reply
I think this is more about being diligent than being patient.
There are plenty (too many?) devs who will diligently try and figure out something but that have no patience when dealing with others.
[+] [-] ravenstine|7 years ago|reply
[+] [-] kharak|7 years ago|reply
Writing codes is completely different. I have to practice everything what others seem to do intuitively. I need checklists. I need to take notes. I need to review my task and codes several times. And still, I overlook the obvious and never spot the easiest implementation (even for trivial tasks like checking for empty Strings). All while it takes me a great deal of discipline to take care of the level of detail that is required.
If someone here has/had the same problem, I'd like to hear their solutions.
[+] [-] dwrodri|7 years ago|reply
I mention these because they rely heavily on object-oriented and/or imperative programming paradigms. With C and C++, I still struggle often with striking a good balance between "writing a short solution that works well" and "writing code which is a joy for others to read". The former often relies on my technical knowledge and produces code that can be obscure to other readers, the latter often requires MUCH more concentration and attention to detail when writing.
However, I have recently started experimenting with declarative and functional Programming. Coming from an imperative background has made "relearning" how to program quite difficult for me, but I've just started to see the "elegance" in higher level functional languages, such as OcaML and Haskell. Of course, functional languages are often MUCH better suited to different problems than OOP languages, but combining filters, reductions, maps and folds seems to activate the parts of my brain that are much more closely associated with the "classical logic" side of programming. I think you should check it out if you haven't already.
[+] [-] addicted|7 years ago|reply
2) Practice and experience. I think for the most part intuition is simply the result of experience and practice.
3) Learning different programming paradigms. Something that has helped me more than anything else I think is learning programming languages that cover different paradigms. I’ve never coded anything useful in Haskell, but just the process of solving basic programming problems in Haskell, with its strong functional approach, helps me identify issues with the proceduaral/OOP code which I do write to solve useful problems. I think it allows me to approach each problem from multiple perspectives so even if I don’t have certain Haskell features available to me, it makes it easier to recognize that this may be an issue I need to address in my OOP code (for example, the Haskell compiler when pattern matching requires all possibilities to be addressed. Awareness of this fact means that anytime I’m writing conditionals checking the input I’m much more aware of the fact that I need to also handle the else condition, something that most non-functional programming languages don’t hsually require in their conditional constructs).
4) Related to #3m opting for better solutions wherever possible. I always try and opt for expressions over statements. I try to avoid state change as much as possible. I try and minimize side effects in functions, and try to constrain them in specific areas of code, etc.
5) Formal CS study. I don’t have a CS background, but studying formal CS in my free time has helped a lot. Getting better at data structures, algorithms, formal verification, etc, has helped develop my intuitions even if I don’t sctually use those data structures and formal verification methods in practice.
[+] [-] voidhorse|7 years ago|reply
Foremost: practice. If you can read and write essays at a college level you've been practicing the craft for (likely) years. Most educated people in the US start engaging with letterforms as soon as kindergarten (!), and no later than 1st grade if not preschool. Contrarily, we don't start so early with the rules of logic nor programming constructs. Most folks don't start programming until much later, and even those who are precocious in this regard usually don't begin using "real" languages (in other words, not stuff like lego robotics or scratch) until they are ~13 or so (of course, there are plenty of exceptions). As with most skills, practice is invaluable.
On a conceptual level, I found that making the jump from asking myself what does this code do to what does this code mean majorly beneficial. It may seem like a minuscule or pedantic semantic point, but it actually makes a world of difference. Just like essays, programs are expressing—they are saying something. If you shift from approaching programming from a goal oriented perspective to a communications perspective your code will probably improve immensely. I think this is the reason guys like Donald Knuth stress code readability and literate programming so heavily—at the end of the day, that's what's really important: communicating some idea—just like we do in plain old english. We simply have a broader audience (the latter part of which is very picky about what it understands). The notion of a proposition in logic doesn't do, it means. Programs are essentially a set of propositions which just so happen to have the side effect that they can make a device (a computer) do something when it interprets them. Just as linguistic commands ("go to the store") are "pure" and free of side effects in and of themselves—they only have effects under human interpretation.
On a somewhat related note, I find stepping away from programming languages and starting with pen and paper is great. I think people tend to let programming languages get in the way of the real nature of what it is they're doing, which is solving problems in a structured manner, using mathematics and logic (algorithms and data structures). You don't need a programming language to do this, it's only a vehicle to express your solution. Just as you'd often start writing a formal paper by exploring your ideas in an outline or notes, or a couple of first drafts in which you hash things out, you can start "programming" by sketching ideas for solutions and better comprehending the problem at hand. This will ultimately help you write better code. I think a lot of self-taught devs, such as myself, miss this part early on as our entry point into the discipline is often through the languages and tends to kind of remain at the level of the languages we like unless we dig deeper into the underlying formalisms driving them. Too often people just go along with their first-pass understanding of a problem and begin reaching for the libraries, language constructs, etc. that they think they need. Someone with formal training, contrarily, has professors that can help them recognize the concepts behind the languages and connect up and distinguish the notion of a language as a mode of expression and programmatic problem solving as a practice irrespective of the selected language.
[+] [-] edw519|7 years ago|reply
OP brings up a lot of good points (who could argue with these), but overlooks my #1 fundamental: If you can't write good code, not much else matters.
I know lots of programmers who have mastered the technical skills but are weak at the other things, so no one would ever mistake them for "senior", no matter how good their code is.
But I know many more "I.T. people" who are good at the "soft stuff" (analysis, design, product ownership, people management, agile, etc.) but can't code. I don't want to sound snarky, but these people are a dime a dozen. They often have great attention to detail and patience, but would you really entrust them to build your software?
Learn how to build software first. Be able to do that well before adding the soft skills.
That's the most important software dev skill needed. And it is most definitely "technical".
[+] [-] mpweiher|7 years ago|reply
Can't stress this enough and I frankly don't understand all these articles claiming otherwise, when even the most minimal reflection would clear things up in a jiffy:
Take a skilled trapeze artist who has great attention to detail (I hope) and is patient (I hope) but cannot code.
Alternatively take a brilliant software developer who is slightly sloppy and not very patient.
Which one do you want writing your software?
Of course, that's accepting that these are important skills/attributes. I don't actually agree they are. See
https://medium.com/@petecam/why-laziness-impatience-and-hubr...
[+] [-] spdionis|7 years ago|reply
Maybe this is influenced by geolocation or other factors, but IME actually competent "soft stuff" people are rarer than competent engineers.
[+] [-] devonkim|7 years ago|reply
[+] [-] BurningFrog|7 years ago|reply
We are all people before we are programmers, so I'd argue it makes sense to build people skills before programming skills :)
But I'm probably misinterpreting you.
[+] [-] rcar|7 years ago|reply
To take a less extreme example, depending on the role I'd still rather hire someone who was occasionally impatient and didn't always write tests but knew how to code really well vs. a fresh grad who's always cheery and polishes the hell out of their work but takes a lot longer and produces meandering code.
[+] [-] scoutt|7 years ago|reply
[+] [-] ken|7 years ago|reply
It's quite possible to teach a conscientious person to write programs. I haven't figured out how to teach a person who writes programs to be conscientious.
[+] [-] bitL|7 years ago|reply
[+] [-] HashHishBang|7 years ago|reply
[+] [-] mobjack|7 years ago|reply
Most of the time they will be satisfied with an 80% solution.
[+] [-] b_tterc_p|7 years ago|reply
[+] [-] cuddlecake|7 years ago|reply
[+] [-] CM30|7 years ago|reply
A lot of people will just build stuff they find interesting/fun to build, but no one will care. What they will care about is whether it solves their problems, and they'll often go for a hacky, poorly done solution that does if need be.
[+] [-] asaph|7 years ago|reply
[+] [-] JoeAltmaier|7 years ago|reply
The absence of this causes havok: a task thought done will turn out not-done at the deadline and become an emergency. A feature not measured against all the requirements will fail in test or worse! in the field and cause customer angst and extra cost to everybody.
[+] [-] gerbilly|7 years ago|reply
Conscientiousness is one of the 'Big Five' personality traits[1], and it is the one most strongly correlated with success in any field.[2][3]
[1] https://en.wikipedia.org/wiki/Big_Five_personality_traits
[2] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2747784/
[3] https://www.businessinsider.com/conscientiousness-predicts-s...
[+] [-] Yuval_Halevi|7 years ago|reply
Some of them were great and some were not so friendly. -Respect for others - Being friendly - Give good energy to the people around you in the office - Learn how to work in a team
Those are the things that when a good developer has, he becomes a game-changing part in a startup
[+] [-] C1sc0cat|7 years ago|reply
[+] [-] stuxnet79|7 years ago|reply
[+] [-] WheelsAtLarge|7 years ago|reply
It took me years to understand this but without being able to work with your team you will not e able to create great software.
It's possible to create a product that's not technically beautiful but it meets a real need in society. Ultimately we create software to meet a need. Once we understand the need we can go back and refactor it. But if we can't communicate and get along with our team then the chances of creating a good product are low.
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] johnrob|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] rarspace01|7 years ago|reply
[+] [-] bpyne|7 years ago|reply
[+] [-] saiya-jin|7 years ago|reply
[+] [-] stunt|7 years ago|reply
[+] [-] linkmotif|7 years ago|reply
[+] [-] brootstrap|7 years ago|reply
I dont care how good your program or app is. If you cant talk like a normal person, accept criticism, negotiate etc. You are going to suck. The best co-workers i have are able to combine both the CS tech knowledge with other skills like good estimation, honest and open communication, clear planning and execution etc.
You can just tell in my opinion. Start workign with someone on a project for an hour and you can tell if they are a nerd without focus who spends weeks doing useless shit, or someone who will seriously contribute to your team and help get shit done.