Hacker News Reader

Hacker News

Comment by hapless | Hacker News Reader

Full thread

hapless

Most of the important skills have nothing to do with technology

- Requirements gathering

- Customer interaction

- "Managing upwards" (dealing with PMs, product people, designers)

- Estimation and planning

- Becoming a team player (Most college students only do a few, short-term group projects. This does not adequately prepare graduates for tight-knit teams in a professional setting.)

Anyone with a little bit of coding background can learn rails in a few days. The hard-won assets are all "soft skills:" professionalism, teamwork, planning. As far as I know, there's no substitute for real industry experience. (It would be awful nice if there were!)

View on HN

Great list. Another that separates the wheat from the chaff is by making yourself replaceable. To an insecure person (in any profession) this is anathema to maintaining a job; to a confident and professional person it is simply a requirement of the job.

- Documenting what you do. If you hoard knowledge or hide it in e-mails or IRC logs you're not helping anybody. If you're guy who changes something that affects other developers but don't send a courtesy e-mail or present your charges (your action being proportionate to the change you're making) -- you're that guy.

- Teaching others your skills. Being a font of knowledge, wisdom and ideas is also important. If the product owner, PM or a junior dev can approach you and get a straight-laced answer tailored to the skill-level individual you're doing really well indeed.

- Every team and company do things differently. Being able to contrast how you're going to do something against what you have done before is another useful skill.

- Caring about the 'boring stuff': release management. configuration management. proper continuous integration. simplifying your build steps. cleaning up hairy code or removing redundant files and gunk from older projects.

> Caring about the 'boring stuff': release management. configuration management. proper continuous integration. simplifying your build steps. cleaning up hairy code or removing redundant files and gunk from older projects.

This. This this this. I just took a senior-level gig as a devops/productivity engineer where pretty much my entire job is figuring this stuff out. It is not stuff that juniors often think about, but it can take up a ton of management and seniors' time to get right so they don't have to.

it is taking up most of my time - but boy the series of blog posts are shaping up awesome :-)

Man. We haven't yet ramped up on devops blog stuff, but already "bloggable" has become shorthand for "valuable and interesting".

yes, it has - strange. I guess it's a function of if you don't have anything worth saying, don't say anything.

>Caring about the 'boring stuff': release management. configuration management. proper continuous integration. simplifying your build steps. cleaning up hairy code or removing redundant files and gunk from older projects.

Sigh careful there. I just got the evil eye from my boss for doing just that.

Only care about this kind of maintenance and future-proofing if you work in a tech-savvy company. In other environments where the suits have no understanding of things like technical debt and the value of maintaining a high quality, they will see this as procrastination.

I would argue that something that comes with experience expected of a senior engineer is the ability to communicate the cost of technical debt in terms 'business guys' understand.

I agree with you, but it is also important to understand when these things are important to the business.

I want to add self-awareness to the list.

When I was reasonably new, but had a project or two behind me, I thought I knew everything that was worth knowing. Slowly, as projects, responsibility and, most importantly, failures, all grew in size, it dawned on me that there was _a lot_ one could know about development.

Today, I know vastly more than I did a few years ago, yet now I feel like I know very little, because I understand how much else there is still to learn.

Now that I've done some technical interviewing for my employer, I see the same thing in others. Some of the best people are those that are humble enough to say that they don't know everything.

And on the flip side I've interviewed someone who rated themself 9/10 with git. I asked for an explanation of the term rebase, and got "huh?" as a response. I also see it in some vendors I cooperate with, young business' with young developers who think they can solve everything simply because they lack experience with failure.

So in short, knowing something of ones own limitations is important. Relevant comic: http://old.onefte.com/2010/06/19/i-am-legend/

On the technical side, I will add "experience with systems as a whole, and knowing what's likely to fail in the future and how to design extensible and maintainable systems". I see junior developers who make things that work, but then are not easily extensible, cleanly abstracted, etc.

Senior developers know what to plan ahead of time, what to leave until later, what questions to ask, etc. It doesn't have much to do with the language itself as with the design of the system as a whole.

I like the analogy of the false summit (https://en.wikipedia.org/wiki/False_peak). The hill that you're currently climbing is obscuring the mountain ahead. :)

This is also true with me...everything I've learned over the past few years has only gone to show me all that I don't know.

And I'm the type of guy that would be totally honest about my shortcomings but unfortunately it also seems like this thruthfulness is seen negatively by most employers (but just because I don't know right now doesn't mean I'm incapable of learning or don't have other skills that are similar and applicable to the new skill).

Maybe he was just so badass with git that he never fucked up master and had to rebase.

Nice list. One thing I would add I noticed is that good senior engineers have an eye for, and a healthy fear of complexity. This usually comes from (painful) experience. Junior people on the other hand like to go and create more moving parts than necessary using the very latest tech/library versions.

A good senior person is not afraid to solve something using a short shell script running from cron. A junior person might be insecure about using something so antique and come up with a Ruby or Node or what have you solution instead.

Antique? Try right tool for the right job. That's far more a distinction.

I'm writing from my iPhone so excuse the shorter message.

I agree that the soft skills are very important but if that's true it doesn't seem to be fully appreciated I. The startup arena and seems to rely more on particular skillets more.

For example I've applied to companies that use Rails and even though I know I can learn it within a short while I've always received a thanks but no thanks message even though my resume, and associated accomplishments short list, show how I've excelled at a wide variety of projects within my organization and been able to work well with a range of different personality types.

So I feel because I'm not a "Rails" guy it holds me back. The other thing possibly, could be I can't really quantify the other usual requirement I see..."building at web scale". Since my organization doesn't really deal with that sort of traffic volume.

Of course keeping on trying is always a good thing, but it's also a bit of a bummer to get the feeling that the skills and experience one has already acquired aren't really appreciated.

If anyone would like to chat further I'll go ahead and check this thread a little later from my machine to give a thorough reply!

I expect a Sr Engineer Candidate to have dabbled in the language/framework before applying for a position. If you haven't put forth the effort of playing with the technology beforehand, ESPECIALLY with such a popular framework, I don't even see your resume... I've asked our recruiters to not bother.

Same with 'Web Scale'. There are SO MANY different ways to gain experience with maintaining high-volume sites. You can generate the load yourself, you can volunteer for your favorite non-profit, you can find a startup that is facing these problems and needs cheap labor.

A Sr. Engineer sees problems to solve, and finds creative solutions. Lack of experience in a specific realm is one of those problems.

Nicely put. I would only add that a senior developer is able to grasp the "big picture" of a project, and would have the ability adapt and influence (not just with words, but with actions and well-researched presentations) the rest of the team and management to create the best outcome for the project.

It all sounds so vague, so it's best summed up as "experience" and "people-skills"

Your comment got me thinking about my personal situation.

I switched to development about half a year ago. Before that, I worked in the industry 7 years as a game designer, producer and created a startup (even found some seed investment) which gruesomely failed.

So, I'm confident that I have the skills that you listed, but calling myself a senior?...

Another crucial soft skill to add to the list: being able to separate important from less important tasks and investing your time accordingly.

Weird, I thought it's just 5-10y of experience in the industry that upgrades you to a senior. Isn't it??

My experience (with smaller companies) is that a couple years of experience and either asking at the right time and right way or switching companies is what it takes to upgrade your title. I've always said that early in your career you need to change jobs every year or two to keep your salary, title, role, etc. moving. If you're at a great company, large or small, you might not have to, but for the rest of us, keep that resume out there. Any time you wrap up a good project or solve a big problem, that's the time to ask for at least a token raise and a change in title.

You see that little triangular arrow pointing up next to his post? When you think "that's a good post", "I agree" or "other people should see this" you click it.

You don't actually post "+1" or any variation whatsoever. Just click the triangle.

You see that little triangular down arrow?

pearjuice wasn't just saying "-1", he was helpfully explaining why asah was downvoted.

Reply on news.ycombinator.com