Top Things Every Software Engineer Should Know
javacodegeeks.com
javacodegeeks.com
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.
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!"
2) Understand the Business of your Customer
3) Minimum One Programming Language for each Mainstream Development Paradigm
4) Know your Tools
5) Standard Data Structures, Algorithms and Big-O-Notation
6) Don't Trust Code without Adequate Test
7) Basics of Project Management, Lean Management and Agile Concepts
8) Key Metrics of Software Development
9) The Root Cause of the Last Defect
10) Understand the Infrastructure
Author says that the list is not ordered.
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?
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.
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 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.
It felt a bit like the lesson is "be servile whenever possible". But maybe I'm misunderstanding the author.
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.
[or was it auto-translated from some other language?]
His English isn't that bad, and nothing about his post shows any evidence that he isn't an experienced programmer.
(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.)
Is it just me or are semantics really shifting?
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.
>> 5) Standard Data Structures, Algorithms and Big-O-Notation
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.
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.
Those aren't really multiparadigm programming languages.
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.
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.
I wouldn't say c# is functional.
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.