That's not a bad list of things to strive for, but the whole concept of "this is what I know, I'm awesome, so this what it takes to be awesome" puts me off.
People can do perfectly well if they are lacking in some of these areas, especially if they bring something else valuable to the table.
Also, I don't agree with the assumption about younger and senior engineers. Whether you focus is on technical or soft skills should be a personal thing, not a function of age. This exactly the attitude that tends to force older engineers into management and out of technical roles.
Furthermore, it seems like the kind of technical people I've who've been quick to talk about their people skills or emotional intelligence have been the worst kind of oafish moron.
It's better than most lists, one of each (procedural programming languages, object-oriented programming languages, functional programming languages,
declarative programming languages) vs learn a LISP.
Well, I am pretty confident that the vast majority of programmers do not know both a functional and a purely procedural language. In my book, "knowing" a language entails having used it in some significant piece of software at the very least. Most programmers absolutely have not done this in ANY procedural or functional language, and very few have done significant work in both.
I guess my issue with these all-too-common HN "things everyone should know" posts is that inevitably 99% of programmers don't know all the things everyone "should" know. If you took the posts at face value, you would feel very inadequate.
A more appropriate title would be "Things I know. Look at how awesome I am!"
As good a list as any, with just a few nitpicks; I'd like the story on (1) elaborated a bit more. Explaining to your manager that your perception of reality differs from hers doesn't seem like it'd warrant losing an ally in the company.
As for (8), I'm not a very metrics driven guy when it comes to my code; Beyond test coverage I've no idea what the key metrics of software development are (at least in "the small", eg not business metrics). Would anyone want to elaborate?
Regarding #1, I've found that it's best not to usurp higher management or do anything that exposes questionable decision-making in front of their peers. Never do it in email chains or meetings.
Whenever I've had a situation like this I do it in strict confidence and don't put it in their face, almost always say to the effect "hey I think I found something, can we grab a room" and go straight to the whiteboard and begin drawing, and use language like "so check this out... I'm a bit worried about this, what do you think?" I let them arrive at the same conclusion I did, or at least start a healthy debate. The great thing about doing this is sometimes you are wrong, maybe not technically, but there are other considerations that went into the decision that you're not aware of.
Also I've learned to not overstep my own bounds, when I have issues with another dept I don't go rogue and knock heads, but go to my own supervisor and ask if they can talk to the sup in that dept and get back down to their respective staff. The only exception to this is for time critical issues, I'll send an email blast to all involved parties first, then walk around and talk to people - ask them if they have time in their schedule to look at something, if not who else they might be able to introduce me to, etc.
Basically everything I learned about dealing in a corporate environment was through making tons of my own mistakes and watching the tv show The Wire and following the "Chain of Command" and seeing quite a bit of Jimmy McNulty in myself :).
All this said, the biggest blowup I ever had was only a year ago, it cost me a relationship with a director a couple levels above me, and it was the result of actually doing something that probably saved the company a cost in the 6 figures for only 3 days of work... it was a combo message of "great job... and you made me look like a fool". I totally get it, I would feel the same way if I were him. But it was still the right thing to do, and sort of a signal that perhaps the corporate world is not for me - or at least that one particular environment. YMMV.
Explaining to your manager that your perception of reality differs from hers doesn't seem like it'd warrant losing an ally in the company.
It's all in how you do it.
Humans are fundamentally social animals, hardwired for status. As a nerd that was mainly invisible to me early on. Two books that really helped me see how it works in humans are Chimpanzee Politics by deWaal and Impro by Johnstone (in particular the section on status transactions).
If you correct somebody in a way that costs them face, they will trust you less. E.g., publicly demonstrating that they're totally wrong in an important meeting, especially when done with irritation and contempt. You can have the same discussion privately in a fashion that's caring and supportive and you'll be trusted more because you've demonstrated that you're an ally.
"I'd like the story on (1) elaborated a bit more."
I would like more detail in that anecdote as well. Anecdotes can be powerful teaching aids if there is enough information about the people in the anecdote and the situation.
I'd imagine that the writer's arguing back and proof that the manager was wrong made the manager look bad in front of other people. Corrections of fact might be better in private. I'm just guessing though.
"As good a list as any, with just a few nitpicks; I'd like the story on (1) elaborated a bit more. Explaining to your manager that your perception of reality differs from hers doesn't seem like it'd warrant losing an ally in the company."
It felt a bit like the lesson is "be servile whenever possible". But maybe I'm misunderstanding the author.
I'm sorry, you seemed to have an interesting story going there but the spelling and grammar put me off finishing it. I think this says a lot more about me than it does you however. (cue next commenter finding the flaws in this comment)
I think because I'm a programmer I rely less on spellcheck than non-programmers, because what I write is full of words mashed together as one (spellcheck if flagged by Firefox's spell checker (and BTW the "if" in "spellcheck if" wasn't flagged by anything)), and words that just aren't words (ngninx). I don't usually add those words to the dictionary, because I'm afraid of writing to a non-programmer and having something pass through that shouldn't.
I treat spellcheck as a real-time shoulder sirfer (surfer), and I generally hit Reply/Send/Make-it-so even though my messages are full of wavy red lines.
The errors I saw (before giving up) would not be caught by a spell check. I'll go so far as guessing that a blind spell check was run, with no human check on the corrections.
Or English isn't their first language. That was my impression. Granted, I bailed partly because of the grammar, too but that was after realizing it was a mixed list of soft skills, not algorithms or tools or whatever. Once it wasn't what I expected, the writing didn't help keep me.
My comment was not meant to mock the author. I truly believe, though, that writing syntactically and grammatically correct and comprehensible English is a very important skill every programmer should have. Code comments and documentation are an important part of our craft.
I agree completely but people will be at different stages in their proficiency. It is good that the author felt confident enough to write the blog. His skills will only improve from that.
(I'm not happy with my own English. It has deteriorated a lot since grammar school. My spoken English is worse than my written English.)
There used to be a time where 'declarative programming languages' was a group name for Prolog, Mercury and friends.
These days, it seems to mean things like CSS, HTML, ...
which are not programming languages in my book.
Interesting observation. I'd also add that learning Prolog would be a much more self expanding experience than the languages listed. I've yet to encounter another paridigim with such a leap in it's learning curve.
This is first-year CS college stuff. There are many good books (this http://stackoverflow.com/questions/3183240/what-book-to-use-... stack overflow might help) and there should be online courses, I think I watched MIT course about a year or two back to refresh this stuff.
However, especially with Python and Django, you won't be really using this, unless you are actually making program to showcase some data structure or algorithm. It is still important, but with high-level languages, the need to know this is more about the ability to reason about software behavior than actually coding the stuff yourself. With low-level software (which means GPGPU too), you would use it too.
Graphs are bit different, but ultimately similar venue.
Strong disagreement on that second point: with high-level languages it's in some ways more important to know algorithms and data structures as you don't have a compiler hiding inefficiency as well (there are many inefficient C programs which just haven't had enough data to matter). The answer is usually “Use the standard library implementations” but knowing which one fits your problem is an extremely helpful skill.
This goes double for anyone writing SQL queries: ORMs are great at hiding complexity until you need to write a report and are back to big-O.
That is what I meant by saying "you won't use it but understanding it is important". I should have said "you won't code it" for it to be more clear, as I meant that most Python probably don't spend their time reimplementing whateversort, but still should understand what it is and how it works.
I disagree with the beginning of your second paragraph. Even when coding just in Python, a solid understanding of the fundamental data structures and algorithms is very important for writing efficient code. Without it, one can't understand the differences between the containers Python offers and their runtime characteristics, and further can't design efficient algorithms that don't repeat too much work.
Introduction to Algorithms is the standard textbook, data structures and algorithms are language agnostic. For Python specific implementations, Google and Wikipedia are your friends.
Well, to be honest you're probably right, and I expected some backlash from this comment. I was thinking more in a cultural and idiomatic sense than technical one. If you were to sit down at most Python and C# projects, the code is going to be pretty object-oriented. Functional programming beyond map, filter and fold are going to be pretty clunky.
I think I was also reacting to this suggestion in general. I don't think it's that important, and the term "multiparadigm" is vague enough that it almost sounds more like "learn a language used heavily in industry". I think it's probably more valuable to learn different languages that diverge drastically, and with object-oriented programming, languages that diverge radically (and sometimes opinionatedly) from the classical Java, C#, C++, Python model. Prototypes in JS, multiple dispatch in CLOS, OOP a la carte as in Clojure... these are all pretty different from classical OO, and have certainly broadened my understanding of OOP, perhaps not necessarily to the benefit of my Java code, but certainly to my understanding of its limitations.
C# is fundamentally OO (especially considering the .NET framework that it's tightly bound to in real-world use), but can be used in functional ways. C# has first-class functions and closures. The LINQ stuff introduced in 3.5 is amazing to work with, giving C# many capabilities of a list-processing language also. I love C# and would definitely call it multiparadigm.
Every language can be used in functional ways, including Fortran, Cobol and assembly language.
I think the main question is "what is idiomatic in that language?" and in that case, C#, even with LINQ, is still not functional (in the sense that Erlang, Haskell, OCaml and Scheme surely are, and Python sometimes is).
For example, when you use select in c# over a user-defined collection, the enumerator might modify global state. It would be bad practice, but it's not unheard of.
C# has closures but why do you say it has first class functions? I'm pretty new to C# but I thought all functions still must be members of a class. Yes you can pass delegates to, or return them from, a function but they cannot stand alone. Isn't that true?
"Hey Markus, you forgot to give me the information XYZ in time!"
The most important thing to realize is that this is a test; he is testing whether or not you know how to play this game; whether or not you can be relied upon in the future to work together at this game against common opponents (not necessarily enemies, but roadblocks). In this case, author failed the test, and boss's-boss now knows that he will never be able to count on author to advance a common goal without fear of putting his foot in his mouth.
I'm a straight male so from my personal experience, women also do this in relationships. They will test you relentlessly, just like your backslapping male buddies will give you shit. It's the same exact game, with inverted strategies. In a sexual relationship or good friendship, you're expected to be dominant and talk back to these tests, in a professional relationship, you're supposed to subordinate yourself to organizational superiors.
It's really not that complicated, you just have to use your brains and your balls at the right times. You don't even really need to be a smooth talker or a great politician, it's really just about context.
This kind of thing is inherent in an elite education, and inherent in some peoples' personalities. Most people without an elite education, elite parents, or natural ability are never taught this, and they basically fuck it up at every opportunity possible until they catch on or are explicitly taught this.
People can do perfectly well if they are lacking in some of these areas, especially if they bring something else valuable to the table.
Also, I don't agree with the assumption about younger and senior engineers. Whether you focus is on technical or soft skills should be a personal thing, not a function of age. This exactly the attitude that tends to force older engineers into management and out of technical roles.