Don't get me wrong, everything in Pillar #1 is important, but I think there are much more important things for an aspiring developer to consider.
Just off the top of my head:
- program structure and organization
- variable typing, naming, & use
- function/subroutine strategy & use
- frameworks & APIs
- algorithms
- database design, structure, & access
- benchmarking
- performance tuning
- scaling
- security
- testing philosophy and strategies
- systems analysis
- systems design
- prototyping
My users/customers are race car drivers. We developers build and maintain their cars. Systems administrator build and maintain the racetrack itself. Every link in the chain is necessary, but in my experience, smooth pavement with poorly running cars is the norm. So we developers need to focus more on building better software and leave as much admin as possible to those experts.
I have yet to encounter a manager (in the enterprise) who actually cared to take a closer look at the things mentioned in your above list. Managers promote those who make their lives easy and make them look good. They care alot more about whether your status report is up to date, if your time sheet is on time and if you are meeting deadlines than what your program structure is.
In fact, as long as it works and conforms to requirements, most managers don't care at all what your program actually looks like and it won't factor one bit into your yearly evaluation.
Granted, a poor program structure and organization may make you fail at any of the above mentioned points, which will lead to poor reviews, but the structure itself doesn't matter from my experience.
To me, as a technical architect and someone priding myself on my work...it does...but not necessarily to management.
I have. Many times. But indirectly. Let me explain...
IT Managers get feedback from our customers. You write better software, you will generally get better feedback. Obviously, lots of shit falls through the cracks that managers/users/customers would never be able to tell the difference.
But here's the rub...
If you don't learn the stuff on my list, sooner or later you will be outed. Someone will need great software and you'll deliver your usual shit. And someone will find out. (Of course, in order to survive, all you have to do is stay one step ahead of the managers and users, and be ready to jump to the next job before you have to.)
Why bother to live like that when the easiest and best way is to just learn how to do things right and get really good at what you do. I think that was OP's original point.
One powerful remedy to this is contributing to open source. Granted that may be easier said than done depending on where you work, but open source is where you can build a powerful reputation based primarily on technical excellence. In some ways this can be a parallel career ladder where reaching the top means you get the best of both worlds: a high corporate salary plus the freedom to work on whatever you want. That's pretty rare, but in my experience even very modest open source contributions opened doors for me in shockingly short amount of time.
> So we developers need to focus more on building better software and leave as much admin as possible to those experts.
I've worked in a small company where there were only 3-4 sysadmins, and besides the usual user support they were also in charge of maintaing a few hundreds of servers. In this situation you don't want to bother the sysadmins with stuff like "how do I check if port X on foo is open? Why is ssh asking for my password?". You want to troubleshoot this kind of thing by yourself, so that admins have more time to build clusters and automate stuff instead.
> The optimal target audience is the following group of people: Professional software developers ...in junior positions ...working in large software companies
I don't work in a large software company (I'm allergic), and as a result not much of this felt relevant to me.
If your goal is maximizing compensation, luck, and being in the right place at the right time has a huge factor also. If you're working on mind-numbing, cost-center corporate systems, it really doesn't matter how on top of the ball you are and how well you organize/communicate, your salary isn't going to grow by leaps and bounds.
After watching the industry and people in it for a couple of years now (and experiencing BigCo software for myself), I'm convinced that the only reliable route to big raises is moving jobs. I've seen many people leave this place for a big raise, and then come back 2-3 years later with an even bigger raise, outpacing even the most dedicated, professional people who decided to stay the course.
So, secret to getting paid in BigCo software land: switch jobs as much as you can, stopping short of being seen as a flake (2-3 years each is good).
And I'm sure that the system administrators were totally and perfectly happy with having a new piece of (possibly improperly configured) software, running on a development box or taking up server space. I'm not saying that its bad to take initiative and bring in the tools that you need to get the job done. Its just that before you do so, you should think a little about what sort of maintenance your solution will require. Will it require updates? Does it need to be configured in a particular fashion to avoid security risks? Is the data stored in the tool easy to export or backup?
A more programming related example is that of the Excel spreadsheet + VB macro "application" created by somebody in accounting that turns into a mission critical app. Typically, by the time management recognizes that their entire company relies on something that's been extended far beyond its initial intent, the code is typically in an unmaintainable state, and significant effort has to go into cleaning it up.
Programmer: "Hey, we could really use a wiki/hudson server/maven repository/whatever to ease the pain on some of this stuff, can we get a box stood up?"
Manager: "The sysadmins are already overextended, I'll look into it, but don't hold your breath"
12 months later: Still no tool.
You only play that game once or twice before you just stop asking and just start doing, or you brush up your resume and move on.
We moved it to a box in a server room and made sure it was being backed up, but we were happy to have it. It solved a business need.
Moms always teach their kids to be a good boy/girl. That only makes you how to fit in with the crowd and be mediocre.
What I learned from Hacker news is completely different.
Have the balls to break the rules. Try new things, new approaches, new ideas and fail often. Take risks, whats the worst that can happen? live and adapt the world to your ideas, build something that people use even if you don't have anyone's approval.
Your career need not be this precious brittle thing that you want to be so careful and follow this many rules to be visible to your managers, not pissing off anyone so that you can become a middle manager yourself someday being a good corporate citizen and living inside a box.
outliers do not follow rules.
But I rebel at the echo I hear of "You have to learn the rules before you can break them." If you're only doing something so that you can defy it at the proper time, you are still obeying the rules so precisely as to defeat the purpose.
The whole point is that _we make the rules_, as a species, a company; as individuals. If a rule doesn't make sense to us, then fuck it. If we create a rule to fix a situation (fail early/often), and it starts failing, then fuck that rule, too.
There's nothing sacred about the system or our understanding of it. Figure out what rules you like, and discard what you don't like even knowing you might come around to it later.
Of course, I've just said what you said (in a sense) with far more words. But I never want to be held to respecting a dysfunctional system just because it currently exists; I want to have to respect an invalid rule because I understand the reasons it is still _valid_--but desire and _will_ move away from it at earliest opportunity.
True, in a way: the take large amounts of coherent risk. That is, a man who wants to be the next Bill Gates may risk his college career to do a startup or make bold promises to get a contract, but he won't avoid showing up to board meetings to practice with his band in the hopes of becoming a rock star. He won't piss people off for no good reason, or for any reason other than which he's focussed on.
This might have been true in 1995. It's not true today.
And Web developers don't need to waste time learning "the bare minimum about Windows," they only need to learn how to install Windows in a virtual machine so they can use IE for testing purposes.
There's a formula you can follow to achieve this. Select an area that is difficult, annoying, or otherwise undesirable to most of your peers. Dig in deeply to this area, and get to where you are an expert. Everyone else will run from those issues and you can step up with confidence. Management will notice this.
I had a coworker like that. He cultivated the reputation of being the go-to guy. He could confidently provide answers immediately. The problem was that his answers were nearly always wrong, to one degree or another. However, there were enough technical layers that his failures could be fudged and nobody on the 'outside' would notice. Said technical layers prevented anyone else on the team from intervening in time for the correct answer to be relevant. This was the same guy who was always busy at work, generally fixing bugs introduced by his code changes, or manually performing tasks that he couldn't be bothered to automate.
Within a few weeks of me leaving for a mail merge call and returning successful and unscathed after 30 minutes, word got around that I was the "go-to guy" for envelope printing and mail merges. All the tickets for this started to come to me.
Ah, so become the go-to guy by never documenting your findings and sharing them.
I think this is actually good (bad) advice: keep your value close to your chest. This, of course, runs contrary to software engineering principles (as well as my own), but I believe you can document and refactor your way out of a job, just as you can fail your way into raises and promotion.
By the way, I don't recommend the above at a 'true' startup, where technical output can and will be noticed. However, once you're at the oh-so-common 'startup' that's been around for the better part of a decade, it's game-on.
Being willing to stand up and take on jobs is important, but one really does need to communicate with management to move up at BigCo, which is what the article seems to be directed toward.
To be clear, my point wasn't "develop some specialized knowledge and then hide it", it was just "develop some specialized knowledeg". And yes, sharing it with your peers is a good choice, but if they were scared of the issue to begin with, they may not all be very receptive to learning about it.
That speaks volumes to me.
HN POST -- http://news.ycombinator.com/item?id=2512740
Part 1: http://memagazine.asme.org/Articles/2010/October/Unwritten_L...
Part 2: http://memagazine.asme.org/Articles/2010/November/Unwritten_...
Part 3: http://memagazine.asme.org/Articles/2010/December/Unwritten_...
And these days, there is no such thing as job security. If your employer cancels your team's product, you will still lose your "irreplaceable" job.
The thing is, after about 10-15 years of work, it seems like one doesnt want to play games like this anymore. Bottomline: Understand programming concepts in depth which allows one to learn new languages/paradigms quickly, and pretty much everything else melts away. Being a good corporate citizen ceases to hold much charm, and the focus shifts to doing good work on one's own terms. And in the process, the realization that communication is important (not just in a corporate setting) already happens and is ingrained.
So for that kind of a developer, this article wouldnt really help. From what I have seen, the HN crowd is mostly of the latter kind.
And yes, unfortunately when attempting to increase salary or position at a large bank or transportation company soft skills do outweigh knowledge of algorithms and the such.
To this point I just witnessed last week one of the best programmers I've ever known be walked off the premises because he was not able to get with the program so to speak.
In a large mature organization that is in the "Management" stage, software is typically built in "delivery projects" where the team is given just enough time to hack together the business requirements then the team is restructured to move on to the next set of business requirements that may be on completely different system with a new set of team mates.
This by default makes things like self-initiative, communication, leadership and organization much more valuable in managements eye than someone who can just write pretty code that is optimized to the Nth degree.
Similar to other articles on hacker news like Jerry Seinfeld's "don't break the chain" calendar, seeing a list of your daily accomplishments shows at a glance how productive you are (or are not) being.
I also find that having a long list of accomplishments can help with motivation and avoiding burnout by providing a sanity check for how far you have actually come when things feel like they are piled up to unmanageable levels.