Hacker News Reader

Regardless of what organizations claim to be looking for, virtually everywhere I've been besides my current position has been staffed to the brim with junior developers, and been in dire need of at least a few people with seniority.

The irony is when a senior person does come in, all their recommendations are ignored because they will slow down the pace of development. Which it will, but in exchange for setting a sustainable pace of development. A senior developer might (making numbers up here) crank out 100 lines of code per day, but a junior will crank out 1,000 while solving twice as many business problems. Unfortunately, bug counts seem to scale linearly with code size, so most of the problems you're solving are actually just a direct consequence of the ten-fold increase in bugs in the larger code base. Eventually progress grinds to a complete halt as it becomes too difficult to add business value, and the company enters zombie mode where its death is virtually inevitable, but can still operate for years through additional funding.

Sorry, I may have gotten a little off point there.

Don't forget that bug count is actually a KPI. More specifically, you end up with JIRA ticket inflation: you get exponentially more tickets generated with time, but the value of each ticket decreases in proportion.

The CEO of the business will basically hear two messages:

1. "Look at how well my tech organisation is doing, we solved 150 tickets this week, a 40% increase over the last 3 months! And yet our headcount only increased 10%."

2. what your comment said.

It's down to him to act accordingly. I've seen many trust 1, he's "data-driven".

There's variations of the JIRA ticket inflation, such as requesting regular update meetings and the tech organisation adapting by finding days-long tasks and pushing off the hard weeks-long ones (since they do not result in neat weekly progress updates).

"I've listened to all the excellent argument for doing nothing, and reaped the consequent frightful harvest. I've watched people hop up and down and call it progress." - George Smiley (in Smiley's People) making the point that this is not a new problem.

Sweet Jesus, so true.

Every time someone suggests we have proper requirements or decent testing or put some thought into design or rewrite something that's causing endless trouble, we're told there's no time for it.

Which is how we're now up to "release candidate" FORTY, four months behind the original release date. Because tests get done six months after the code was written, whatever doesn't fail has a fifty-fifty chance of not actually doing what's needed (so it's a bug), and testers and coders have long conversations about "what's it even meant to do, anyway?" that are unanswerable because there is no requirement or design reference.

The cost of running four months over schedule thus far is, well, four man-months multiplied by the number of employees, basically. So yeah, excellent savings compared to having spent a couple of days thinking about what we're trying to build and having testers involved throughout rather than just dumping six months' worth of untested development on them (and expecting them not only to be able to test it in a week, but expecting everything to pass).

Wouldn't mind if this was the first time, but EVERY DAMN CYCLE is the same. We can't possible start doing things properly, look how far behind we are! It's like there's a mental gap, some kind of inability to see the cause and effect right in front of their faces.

( Morale is low :p )

> Every time someone suggests we have proper requirements or decent testing or put some thought into design or rewrite something that's causing endless trouble, we're told there's no time for it.

I should point out that as professionals not only do we have the option of saying no to bad requests, I think we also have the obligation to do so.

I know there's this culture in software development of "just do whatever the bosses say", but as far as I can tell it's not a law. I've told executives no on many occasions and so far I've never been fired for it. At first their startled, but if you keep saying no to the bad requests and help them understand what they're supposed to do, they eventually come around. And if not, this is an excellent time to find another software development job.

> It's like there's a mental gap, some kind of inability to see the cause and effect right in front of their faces.

Yes, that definitely happens. Until people experience it the other way, they often think that's just how software development has to be.

"I should point out that as professionals not only do we have the option of saying no to bad requests, I think we also have the obligation to do so."

Indeed. I watched three people say "no" to a significant, new piece of very important software that replaced completely our legacy data storage/fetching/processing methods. They said "no" for the reasons you'd expect; not properly specified, unreasonable expectations of basically magic on the part of management, very improbable timescale.

In one meeting, when a very skilled programmer (who goes to the C++ committee meetings and that sort of thing) said "no", the response was "Well then I'll find someone who can." What they got, of course, was someone who didn't say "no" (and of course, there's an element of self-selection here; given that some skilled, competent software engineers said no, the person who said yes was, harsh as it may sound, an adequate programmer but an incompetent software engineer). What we got was a total car crash of software, six months late, that's massively unsuitable, doesn't do what's needed, undocumented, untested, everything bad that you'd expect. A great deal of the 40 "release candidates" were desperate fixes to this car crash, that our recently appointed new software architect is planning to take outside and execute in the car park as soon as we get a "release". So that was a great use of a year.

Where this is going is that saying "no" didn't actually stop them finding someone who wouldn't say "no". On the plus side, the person who delivered this truly atrocious software to us is now actively looking for another job. Not that he was fired, no no, but he's now got zero credibility and nobody wants to work on anything he ever touched.

Christ, I wish I'd just gone into mathematics.

I'm not quite understanding. The yes-sayer worked alone on the project and is now leaving? If so, why's it a problem for you?

Because he's not taking the godawful software with him. That's staying.

It's also a problem for me because he's done his damage. I want to make high-quality software, on time, that does what the customers need. I want this out of both a sense of personal pride, and also because I need the company to keep making sales so they can keep giving me money.

Sorry, I'm still not understanding. What's stopping you from making high-quality software on reasonable schedules?

I don't run the company, and even if I ignored everything I was told to do, and didn't get fired, and instead followed sensible, professional processes, I don't write the entire software by myself.

I am bemused that someone of your experience has trouble grasping this. I thought perhaps you were some kid straight out of school who thinks the whole world works like the marketing material for agile, but it turns out you've got a decade of experience. You must, surely, have seen (or at least heard of) companies that don't look like the marketing material for agile?

Sure. Mostly when I see it, it's people who don't know any better. With a fair number who do know better but do it anyhow. The former group I understand. But the latter is a mystery to me.

I think one big problem is that job postings these days are either for 1) super-specific skills, which necessitate years of industry experience (or academic research, in a few cases), or 2) experienced all-purpose programmers (to save money over hiring several niche experts).

To use a personal illustration, at my old job I had a group composed of about 85 programmers, 15 QA, 5 devops and 5 DBAs, with a few miscellaneous non-tech people (PMs, analysts, etc). In that situation I was perfectly satisfied hiring junior folks with only 0-3 years of experience but a good head on their shoulders and a desire to learn, because there was enough slack in the larger org to make up for temporary slowdowns resulting from training & general learnings. In my current role, I have a team of a half dozen, 4 of whom are skilled analyst/PM types. If I want to build something, I either have to outsource or hire one of two of the very best "full stack" developers that I can trust to throw anything from front end design to web + mobile dev + data structures & reporting/analysis on the backend. As a result, I'm almost always searching for people with 10 years of industry experience who have spent all that time learning & practicing a diverse set of skills.

I think one thing that'll cause disappearance of low end jobs is the upcoming/increasing automation of business processes using click & drag workflow platforms (and better leaner ERPs & CRMs). My previous employer has about 200 IT people just keeping Oracle running, and another 150 or so working on manufacturing software. I think the majority of those kinds of jobs in big enterprise are going to disappear in the next 10 years... and that's A LOT of jobs. Fortunately, one of the triggers will be retirement of boomers, so it'll be a more natural progression than massive layoffs would be.

My anecdotal experience from a recent job search suggests that many employers ask for senior devs but will quickly settle for someone when their requirements and pay expectations are out of kilter with the rest of the market. I applied to a couple dozen positions (mostly asking for more experience than I have), had interviews with a decent number of them, and was eventually hired for a position that had asked for a lot more experience than I had. Turned out they hadn't managed to interview anyone at the seniority level they wanted and decided to go with their best interviewee rather than go through another search (at a big place where HR mandates searches as a waterfall process to use a SDLC analogy). I would wager than in these situations fortune favors the bold, regardless of what the job ad says.

My impression is that "rockstar ninja" keywords indicate that they are paying entry-level wages, and really want someone who is willing to try really hard - and, of course, talk big about how awesome they are.

I suspect that most "rockstar ninja" positions actually end up being filled by people like what I was when I was 17, by which I mean, smart kids who aren't afraid to bite off more than they can chew, who don't necessarily know nearly as much as they think they know.

So yes, if I'm right, entry level positions are still there... you just have to convince them that you think you are a "rockstar ninja" (I like to think I'd be embarrassed by that, even at 17... but realistically? 17 year old me would probably eat that shit up.)

Why did you choose to try and put together a curriculum yourself instead of working through one of the existing ones on the web? Do you plan to make yours available online for others?

Seconded. That sounds like a really useful resource, and could be an awesome recruitment tool for ianamartin. (Just like Matasano's crypto-challenge already is.)

I've looked around at a lot of things online over the course of the 10 years or so that I've been teaching myself this stuff.

When people started asking for my help, I couldn't think of one particular resource to point them at that would give them a wholistic idea of the things I've experienced to be important in my career.

I don't mean this as a critique to any of the fine programs out there. Many are very good and have been valuable to me.

I do plan to make my course of study available online. I'll be getting feedback from my friends as we do this, and that will adjust some of my choices.

Some companies only list "senior" positions with the expectation that more "junior" developers will apply anyway and they can hire people into the appropriate level.

If my experience is any guide, the difference is that there are a lot of very junior people on the market now. For every qualified applicant I got, I got at least one applicant fresh out of one code school or another. The posting was very clear that I wanted somebody with minimum 3 years experience and who could mentor junior developers, but they applied anyhow.

So if there is a smaller number of positions advertised, I think it's just because they don't have to advertise to find junior people. But personally I'd encourage you to teach your friends, as my hiring strategy in the future is to build teams that are really good at taking junior people and leveling them up.

If it's a larger company, then the hiring manager is negotiating with the HR department to come up with a list of keywords and other criteria that HR can use for filtering. This can be a nauseating process, and it may take a couple of tries at crafting the position before any appropriate candidates get through the filter.

I've been passively looking to get out of my troubleshoot Linux job to development. It seems like there is only internships or senior jobs.

I guess an anecdote but managers at my company don't hire entry level developers because they don't want to pay what they can ask for and don't want to wait for them to get up to speed.

I seem(anecdotally to be seeing the same).