Web Development as a career – the realities
docs.google.com
docs.google.com
You can't have it both ways. You need to find a way to evaluate people and, through that evaluation, grok whether or not they can pick up a new technology that they aren't already familiar with. If you can't figure that out, your interview process has failed. Think about it: the complexity and difficulty of your own problems vastly exceed the difficulty a senior engineer faces learning a few new frameworks or APIs. If not, you're doing something pretty trivial.
The best people I've ever worked with weren't people who a priori understood the technology stack we were working with -- instead, they have been seasoned engineers who know how go out and learn, and then apply what they already know in a new environment. This seems so obvious I feel silly even writing it down here, but this is on the front page, so it must be resonating with folks.
What tptacek has said about .NET developers working at IT departments at huge organizations really rings true here. If you immediately write someone off because they work with technologies you don't work with[1] then you're doing it wrong.
1. Assuming you're not looking for a quick, contracted hired gun for something fairly straightforward.
[2004] http://queue.acm.org/detail.cfm?id=1039523
"So I think the lack of a real computer science today, and the lack of real software engineering today, is partly due to this pop culture."
"Like I said, it’s a pop culture. A commercial hit record for teenagers doesn’t have to have any particular musical merits. I think a lot of the success of various programming languages is expeditious gap-filling."
I don't think it's possible to avoid a pop culture with that many young and inexperienced programmers, especially with a cultural emphasis on self-training over mentoring.
Maybe that's how his workplace treats junior devs, but the reality is that a developer with very little experience but a lot of skill is someone who can add a lot of value, and can find a workplace where they'll be able to do that. If you try to make a great junior dev "pay their dues," well, they have better options, with companies that will use them more sensibly.
His related advice actually really resonated with me, basically just to be humble.
"However with one or maybe two of the students I sensed overbearing confidence that now that could write some code and create prototypes they were valuable commodities in the industry."
I've also come across this kind of person who's sure they can do no wrong, and there's no one worse to bring into an organization. Anybody that's gonna come in and do things their own way, not bothering to spend time learning how the team and codebase works and why, will cause a lot of friction. But when it's a junior dev it can be a lot more destructive because "their own way" will often be flat out bad as opposed to just incongruent with the way the rest of the team works.
Tediousness is in the eye of the beholder. I enjoy coding, and as a junior developer (~3 years exp.) I get to spend the majority of my time doing that.
When I look at the more senior developers all I see is that the better you get at writing software the less they have you write. Their days are filled with meetings, emails, triaging bugs, and reviewing other people's code.
I've had a hell of a time interviewing for just this reason. For the first set of interviews, I was emphasizing my experience with patterns as opposed to technologies. That didn't work. I was routinely dismissed, despite decades of industry experience.
When I decided to grind through the latest buzzwords, and build a few sample apps, that's when interviewers got much more positive.
It's not how I would have interviewed people, and I do agree with you and tptacek, but it was an eye opening experience on how to play the game.
> The sad fact is that these people have not been aware of the realities of the industry they have been working in. Their job and their job security is no longer secure. Never let this become you!
It sounds like the author values language/framework knowledge above expertise. Speaking as a backend dev I find as you move up in seniority it becomes impossible to keep up with the latest technologies. Learning management skills, being move involved in architecting and business development all take time. You may end up doing code reviews, project management and cleaning up the 'legacy' (read broken) parts of the system. Does that make you less valuable?
To a company that insists on every part of their project being built in the latest cool language/framework (and yes, I still class NodeJS as this) then yes. To a pragmatic company, which may choose NodeJS if it's the best fit, or Rails, or PHP, or Java - no.
We're back at the skills vs language debate, one which I thought has been done to death.
Maybe 5 years is insufficient, to be considered senior, but isn't the amount of time you've been coding what defines how senior you are? I get that technologies come and go and you have to stay up to date, but I would think that if someone were looking for a senior developer they would be looking for someone with a lot of experience, not necessarily someone who knows the ins and outs of technology X.
Can anyone shed some light on this? It just seems bizarre to me that if you want to be a senior developer you'd need to either stick with the same technologies you used before..
No, the theory is much more valuable. Plus, it doesn't fall out of fashion the way frameworks do.
20 years experience, on a wide range of technologies, in a variety of roles, then we'll talk senior. Until then calling yourself "senior" just invites people not to take you seriously.
Our industry has a significant salary cap, since 27 year olds hold "senior positions", the 47 year olds aren't going to be making much more than them.
I've heard it from people who've been programming for 30+ years, whose idea of code versioning is the 'Save As' button. I've heard it from people whose entry to technology development was coding websites in HTML 1.0, who've learned very little else since.
Many people, at least from the previous generations of programmers, either don't appreciate or aren't able to manage the lifelong learning required by this profession.
Myself, I'll take those 45 years of progress, thank you kindly :)
Depends. After 5 years of being a senior developer, you might begin to think about being a junior architect or tech lead of some sort.
Now, I think I was a pretty senior developer after 5 years, but then I also had preprofessional experience going back another 5 years, and a few years of hobby experience before that... :P
Seniority means, to us at least, experience (i.e. beyond "don't know what you don't know" and at the "know I know some stuff but there's a lot I don't know" stage) and the ability to rapidly pick up and grok new tech, languages, ways of working, and what have you.
It's not about a certain level of experience in Node.js, or whether you have used the shiny new tech that came out last Thursday - it's about whether you can.
Web development is just a _type_ of development. You're creating a hierarchy where none aught to exist.
I've known many system programmers who said the same thing about data engineering: "what kind of a lame made up job is that? They write Python and SQL queries, wow, that's barely programming."
It's all non-sense. You can employ techniques which vary over a wide range of sophistication to create web pages, embedded systems, or ETL pipelines. There is no clear cut hierarchy.
source: Have worked as a web dev, data warehouse engineer, and release engineer.
I've done embedded work, application work and now I'm doing web development. I often seen the "5 year senior wannabes". Hell, after 5 years of work, I was one of them! I refer to my old self as a "hotshot ass hole programmer". They are common.
These days, I think a junior developer is someone who needs assistance to get their job done. An intermediate developer is one who can get everything done without assistance (although they may still benefit from assistance!). A senior developer is someone who can bring up everybody else's level -- getting assistance in this seems to be a critical prerequisite for success).
I tell this to people on my team, but again it is hard to judge your own effectiveness. There is a lot of hubris. I know -- been there, done that, slept in the t-shirt for over 20 years. Thinking about it, I think the key piece of experience that can help you be a good senior developer is to watch a system that you built collapse under its own weight. Coming to grips with the idea that all of those things you really believed would definitely lead to wonderful software were just... wrong (and it doesn't matter what it was that you believed here).
Yeah, I like to assume this is the weakness of job-hopping/stack-changing candidates (as opposed to my not-so-glamorous self.)
Everything you build will fail and need replacement somehow, but you can't improve if you're always gone before it happens.
It echoes the same criticism we (tech-folks) often level at short-sighted Dilbertian managers.
Generation X (and even more so generation Y) are cultures of immediate gratification. I’ve worked with a staggering number of engineers that expect the “career path” to take them to the highest ranks of the engineering group inside 5 years just because they are smart. This is simply impossible in the staggering numbers I’ve witnessed. Not everyone can be senior. If, after five years, you are senior, are you at the peak of your game? After five more years will you not have accrued more invaluable experience? What then? “Super engineer”? Five more years? “Super-duper engineer.” I blame the youth of our discipline for this affliction.
http://www.kitchensoap.com/2012/10/25/on-being-a-senior-engi...
IMO the observations provided by the OP are not sound reasoning for the above conclusion.
In a recent gig where I was responsible for helping the company hire new developers I made a conscientious effort to avoid making such sweeping generalizations. Web development is one of the most diverse fields that I know of. So much so that in my mind you can't assume a qualified employee has ever touched the specific technologies you use in your stack.
I think the hiring practices described by the OP may be the dinosaur here.
Its not so fine, when you have kids and a wife to look after.
Probably have about an hour to myself everyday.
It's one thing if you're a consultant in a web development position where your team is constantly jumping from the previous best practice to the next; keeping up in such an environment is easy and you'll get paid to do it. The problem occurs if you're in (e.g.) a back-end position where your job duties require you to focus on slower-moving technologies that might have lesser demand in the market. What happens if you lose your job after 5 years? Unless you spent all your weekends working with the latest hot frameworks, you're (mostly) screwed.
There was a good essay a while ago which stated that software developers need a professional association. If we were organized, we could put forward the very reasonable demand that a small portion of our on-the-clock time should be spent for education. I think this is a requirement if we are not aiming for a world of 40-year old burnouts and early retirees.
But then, computers and software change so much more rapidly--and arbitrarily--than other fields, that it's very different. Software is as much art as science, and a lot of "keeping up-to-date" with software is simply learning whatever is popular at the moment, not what is necessarily more advanced, better, or newly discovered.
Why? How is this any different from working an extra... 4 hours a week? It sounds like long hours are fairly common, and we tend to be on salary and not get paid extra for that either.
But yes, having the legal right to take 4 hours a week out of your schedule to stay up-to-date would go a long way towards alleviating the problem.
For one, (speaking as an American) unions are sneered at as a waste of resources by your average citizen.
This leads to the second problem: there will always be a pretty decent sized group who do not believe in unions, meaning companies will have a choice in who to hire. It's usually not in a corporation's best interest to hire a unionized worker, at least not a corporation which views "profit" as their primary goal.
We need to make sure that we aren't getting taken advantage of by our employers (examples: shitty pay, terrible work environments, bad equipment, conspiracies to lower wages), aren't implementing poor practices (things like backdoors for the government), and aren't subject to things like sexism, racism, ageism (as you age and learn more and get better at what you do, its going to be harder to get a job - does that seem fair?).
I'd prefer to be part of a tech union that helped ensure my safety in these areas.
admittedly i don't know enough about unions to know how the current structure would benefit our industry, but we need something similar at least.
Show me a unionizeable programming job and I'll show you something that's about to be replaced with a library or shrink-wrap app.
A comparison to law/medicine is more appropriate.
Which are both regulated and treated completely differently than the tech industry. I speak of unions because the way we are treated (not the level of skill) is more akin to a construction worker.
We could have stuck with C, and concentrated on developing new things, but the programming community is like Hollywood remaking the same film over and over with different stars.
[1] https://news.ycombinator.com/item?id=9203045 [2]
[2] That was easy to find...
As for the overall topic, I think I agree. It seems to me that server-side technologies are better researched and understood. But then you look at client-side technology, it's chaotic. Building and maintaining user interfaces is hard... Recently I've been playing around with flux and react, and I feel like it's definitely a step in the right direction towards building simple components that can be easily maintained and extended.
> The honest answer for most people is no!
I find this weird. I advertised for calculator program requests in high school because I wanted someone to tell me what to code. (There were no takers. One guy wanted a program to convert decimal numbers into fractions, but that's already built into the calculators.) To me writing a program is solving a puzzle. You can't do that unless there's a puzzle to solve.
I was baffled and enraged by the prevalence of the question "what do you want to work on?" and its related forms in job interviews. My philosophy of work is that the whole point of having a boss is that they tell you what to do and you do it. Sure, I don't want to fix cars, but that's why I'm applying as a software developer and not a mechanic.
You are a mercenary. That's the idea of a job. You do something, they pay you.
I perceived the emphasis as being on the how to work. I once worked for a company that "believed" in "the one" PHP framework (developed in-house; terrible), "the one" cache (memcached - had to fight to get redis for the richer structures that we really needed; lost), "the one" DB (MySQL 5.0?), no staging environments for devs (we won a battle and allowed ourselves to run vagrant! woo), etc.
In your car mechanic analogy: you don't get to pick what cars to work on, and this is completely reasonable. But, it should be up to you & your team to pick the tools. If some idiot in the company once managed to undo a bolt with chopsticks and liekd it so much that he made it a company mandate, you'll soon be looking for another garage.
Long story short: I've seen the extreme of non-techies micro-managing technical decisions, and it is extremely frustrating. <lablab.png>
Then they go onto say that you need to keep your technology current, and always be moving on. Okay....
So how does one become a senior in his position when you're always suppose to be moving on? By being a master with PHP? Not much has survived/been popular for >5 years that will make him happy.
There aren't a lot of folks who understand how to administer a modern Linux system anymore; even companies using AWS or Rackspace or GAE will need someone versed in the arcane ways of System Administration as they grow.
For "Web development as a career", the OP seems mostly to mean as an employee. Then I'd say, go down that road if you have to, but ASAP learn the business side, get your own software development environment (likely you already have it) in your own room at home, and then just be a sole proprietor in business much as a guy who owns and runs, say, a pizza shop, is a CPA, mows grass and plows snow, is a plumber or electrician, a car repair guy, an auto body guy, etc.
Then you get some big advantages:
(1) You are the one who gets the revenue and, thus, keeps the earnings.
(2) Likely for each dollar of revenue, you have lower overhead than any employer and, thus, get more money. In particular, you get to cut out the fraction of the revenue going to the owners, managers, marketing guys, lawyers, HR, landlords, business insurance agencies, etc.
(3) You have some tax advantages, often well known to sole proprietors.
(4) For your technical qualifications, you only have to learn and use what you actually need and find useful. So, you don't have to play buzz word ice hockey with some HR clown who doesn't know fixed from float but has a checklist of C++, Python, Ruby, MongoDB, Jason, HTML5, ....
Point (4) is crucial: Likely your customers just want their Web site developed, running, and occasionally revised. Okay, that's what you need to be able to do. But, you get to select the framework, languages, libraries, development environment, etc. If you need a new tool, then, sure get, learn, and use it. But you don't have to spend a lot of time learning, say, HTML5 or SVG if you don't need to use them yet.
"The business of America is business", and in practice from crossroads up to the largest cities a lot of sole proprietor small businesses.
What was considered best in class 5 years ago is literally frowned upon now as the technologies and the standard of our applications have evolved rapidly.
Moreover, what was considered best in class 5 years ago can now be set up by a non-expert.
[1] https://www.reddit.com/r/cscareerquestions/comments/2yb11f/i...