michaelvkpdx

Intro articles like this do a lot to reveal biases and misunderstandings. Like with Java.

The article says "Java= enterprise" but I can tell you the best user experiences I ever saw delivered over the web were those done with Java Web Start (not applets- applications launched in a JVM from the web). I developed several in the day that continued to run for years- because users loved them and they were safe and secure.

Why Web Start didn't take over, I have no idea. It was also a superb platform for mobile delivery.

"something incredible will emerge for the right-brained bourgeoisie and literati."

Yes, a real quantum computer. As long as we're dealing with 1's and 0's, there's an insurmountable barrier for those who would get creative with computing.

You're living in a pretty isolated world, my friend. I'd say 90% of my friends would be the audience for this. I've been coding 20 years, most of my friends are successful, grad-degree educated people in a variety of fields, and some of them are even my coworkers.

Who is supposed to teach people what code is? Our schools? Who with a CS degree and programming experience would willfully choose to teach in the USA's education system?

Or maybe the companies who make all their money from code? I think not- it wouldn't help the economic position of Apple, Google, FB, or Microsoft if everyone knew what code is and how it works. It strengthens the tech economy's stranglehold on society when code is treated as something inscrutable.

So there's really very few resources for people- even educated, successful, technically literate folk- to grok "what is code?"

Many coders would do well to read a similar article, if there was one, called, "What is Society?"

As goes the recruitment, so goes the employment.

If you wanted to work for an organization where everyone likes to show off their skills to one another in the interviews, you'd have gotten the job, and you'd be one of them.

The best interviews I find are like a first day of work (but unpaid). Your experience and skills are established by resume and portfolio. The interview shows whether you can work with the team and wrap your head around the org's problems. If you're having to show off- well, that's how your work will be, too.

Google's interviews convinced me, years ago, that there's no way I'd ever want to work there. And that feeling hasn't changed one bit. Much like FB, it's an org whose coding needs are really pretty trivial and the real work was done and finished a long time ago (but there's plenty of need for debugging, egos especially). If you want to work there and surf the gravy train, cool for you.

This wouldn't be happening if we had a true estate tax in this country, and if we didn't allow corporations to sit on piles of money while laborers slave away.

We in the USA are wealthy enough as a society that we all could thrive on 15 or so hours of work a week, if we didn't have to subsidize the fortunes of billionaires.

Corporations weren't citizens in 1776. It only took us 100 years or so to fuck that piece of it up. Nothing in the original Constitution or Declaration requires capitalism.

Fire this guy and dismantle the FBI. Does anyone remember why we fought the Revolutionary War, why we follow the Declaration of Independence and the Constitution?

This joker should lose his job. He does not represent the values of this country,

Sounds like this dude works for Her Majesty's Secret Service, not the USA. He should be fired for this.

One of many incredible books from the 70's, when science and humanities were interconnected and writers were exploring the edges of possibility.

Then Reagan came around, fear was restored, and corporations took ovet education. So much great work from the 70's and 80's and early 90's has already been lost, as young people assume everything worth learning is on Google or will get you a Valley job.

Is this how the Dark Ages began?

Try eating "pure information". Or building shelter out of it.

I hope this drags on forever. It's fun watching pigs in mud, aka lawyers in the Valley.

Good post, but since learning how to be kind isn't on Google's list of things you need to know before becoming an engineer, it's not an important skill. Right, HN?

All professional programmers should continually read Martin Fowler's "Refactoring", in the same way English professors read Shakespeare.

"Refactoring" does not mean "previous programmer was an idiot". Often, the understanding of the problem and the way the code is used change over time. Refactoring is a way of bringing the out-of-control weeds back into healthy symbiosis with the larger garden of code.

I stopped telling clients a long time ago that I'm "refactoring" and instead I just add some extra time to all tasks to account for refactoring on legacy code.

One more thing- pairing is an active process, in the moment, while code review is reflective. During coding, you are exercising a lot of "instinctive" skills, and in a pairing environment, you are pressured to act.

Code review happens after the fact, and gives the developer and the team a chance to reflect on what was done and to use deeper, slower skills.

I'm well aware that our Twitter-fueled society is trying to eliminate reflection as a practice, but thoughtful reflection is a tremendous source of learning and growth. Removing reflection from the coding process limits the growth capabilities of the team.

100% pairing might sound good in the short-term, but you're going to fry your developers. You'll also limit the productivity of your developers, who may be inclined to take more risks when working solo than when working as a team.

By eliminating code reviews, you've also limited the audience for some of the new discoveries, successes, and failures that developers will make.

I remember vividly the push for 100% pairing in 2000. It's a great idea for the short-term on well-defined, low-risk projects, but for anything spanning a longer period of time, it's a productivity-limitiing strategy that can burn out your devs, especially the more introverted ones.

All things in moderation, including pairing and code reviews.

Great beginner tips!

I think your suggested rate calculation (15% above salary divided by 2080) undervalues the rate. Your overhead as an independent includes additional employment taxes, retirement contributions, hardware, software, utilities, and space. In addition, you are taking on risk that is built in to your company-provided salary.

I believe you should strive for 100% above your salary. If you make $100K, your goal should be $200/hour, especially if the engagements are small/ side work. You probably should not settle for less than 50% above, as you are setting a rate that you will use if your side work becomes full-time (which it very well may).

Don't undervalue yourself. And don't count on going in at a low rate and raising it later. Set a rate that reflects your true value.

Remember, companies pay $250+/hour to large firms for specialized consultants whose take home pay might be $100K. That's who you're competing against.

Brilliant blog. Thank you for writing this. Optimization is important! You don't have to tune everything to the fastest possible speed. But remember, in web programming, you may be writing a function that is called 10 or 100 or 500 times per request. That little optimization will add up quickly.

Be smart when developing, and know where the easy optimizations and common pitfalls are in your language and toolset. Optimize as you can without sacrificing maintainability.

"Then what will you do, if you don't want to tell Big Brother where you are going?"

RMS is right on again, as always. The problem is that the younger generation wants Big Brother to know everything, and that is sad and scary. One need look no further than the comments on this thread for proof.

We are not teaching our children the value of humanity, and the way that privacy creates a sense of self. "Self" is now what you make it on Twitter/Facebook/SocialNetDuJour. Sharing everything in a way that government/Facebook/Google can monitor ("Big Brother") is like breathing to the youth who've had iPhones since before puberty.

So many younger programmers think RMS is absurd. They don't even have context to understand where he comes from. RMS has been foretelling the future since the days of the GNU wars. He's an ideologue, yes, but one whose points have always been valid.

Even the term "Big Brother". It's from George Orwell's book "1984". I wonder how many younger programmers would know that.

Typical self-service from yet another rich VC.

Founders don't want to do anything to improve US society as a whole. Investment in education? Retraining workers whose skills have become dated? No- that's expensive and doesn't benefit the rich as much as another steady supply of below-market cost labor.

It's funny that so many of the VC's and Valley elite rail against the ills of the earth resource extraction companies (oil, coal, gas, etc...) yet see no harm in doing the same sort of scorched-earth work with human resources.

This is so screamingly correct. Let's go see the startups hire some old COBOL (or now, VB) programmers and train them on the new stacks, before we listen to anymore of this "there's not enough programmers in the USA" garbage.

It will never be in the best interests of the United States to admit anyone into the country to please the desires of the stock market or of large corporations or of wealthy venture capitalists.

There is nothing, other than a modicum of education, that separates a talented software engineer from a talented fast food worker. I've seen plenty of engineers who I'd never trust with a burger or a grill.

No- you're thinking of the railroad builders (1860's-1870's). By 1900, when the railroads were into their big boom, most of the imported construction workers had either become citizens or given birth to the next generation, who were citizens.

I guess should have clarified that I meant the engineers, brakemen, locomotive builders, and mechanics, and not the well-known Chinese and Irish immigrants who made up the workforce building west.

Part of the reality of founding a company in the United States, and taking advantage of the freedoms and protections being in the USA offers, is that you have to work with the USA labor force.

If you don't like it- well, go international. Fast food restaurants don't get to import the best burger-slingers from Germany. Software companies have to live in the same space.

And it's complete and utter BS to suggest that there's no way we can make up for the gap in our education system. You have to invest in the society, and it takes time to train people. Railroads in the 1890's didn't suddenly wake up with a million trained workers at their disposal, and they didn't have the option of importing trained workers from the UK where railroads were booming. Part of the limits of their expansion was the need for training- and when they didn't train, they ended up with dead workers (25,000 out of a force of 1 million killed on the job in 1900 alone).

If someone wants to come to the USA on their own volition, and take their oath of citizenship- fantastic! We should all welcome them. But it is not up to corporations to dictate terms of citizenship at their convenience.

Thank you for this. I am going to search this one out.

Pragmatic Programmer is pretty good, but even better are Steve McConnell's books from the late 90's, "Rapid Development" and "Code Complete".

They're both big and both published by Microsoft. Two strikes, yes, but don't be fooled. These books have so many nuggets that I've gone back to again and again as a programmer. "Code Complete", in particular.

Neither book is a cover-to-cover read. They're both books you dip into for a tip, a skill, some perspective. But they've held up amazingly well, and for my money and time, they're both a step up from the Pragmatic Programmer. If you like what you found in "Pragmatic", you'll love "Code Complete".

I just wish it wasn't from MS, at the peak of MS evil in the 90's.

"The Circle", by Dave Eggers. Narrowly edging "Mr. Penumbra's 24-Hour Bookstore" by Robin Sloan.

I've been in tech a long time. I came up in the early 90's when the Internet was a tool for collaboration, meeting new people, and taking down the evil bastards.

But since the advent of Facebook, Google, and "pervasive computing", I've been haunted by the sense that what was once good is being perverted in ways that are destroying what makes humanity great. It's always been hard for me to explain that feeling in ways that make sense to those who haven't been part of the wave, whose first computer was an iPhone.

"The Circle" is fabulous because it brings this sensation to life in a way that casual readers can grasp. It's great because it captures what's happening. I only wish it offered a proposed solution that goes beyond living in a bunker.

Honorable mention, for similar reasons, to Mr. Penumbra.

Java doesn't suck, not at all. I still find it to be the most productive language for developing systems big and small, mostly because it's well-understood, the pitfalls and traps are well-known, and the community is extensive and supportive, for the most part.

Java got a bad rep because in the late 90's, enterprises hired anyone who had the word "Java" on their resume, with no real assessment of their actual proficiency in the language or programming skills. As a result, there was probably more bad code written in Java than any other language in history (including VB- you just can't write as much bad code in VB as you can in Java if you really (don't) know what you're doing).

Much of this bad code ended up running flaky enterprise systems. So much bad code ended up in closed-source products (like Websphere, and like many JDBC drivers) that were sold to people who didn't really understand technology (but knew Java was sexy!) that Java itself got a bad name.

No, the language isn't perfect. But with all the lessons learned, and with the great developments in Java since Oracle took over (I cannot believe I wrote and believe that now), I contend it's perhaps the single best language for general purpose software in 2014.

The things James talks about in this article are all big problems that have less to do with the language than with the poor development practices that became so endemic to the community as a result of the rush to hire anyone with a pulse to be a Java programmer 15 years ago.

Downvoted to -3 for suggesting that software engineering can cause brain cancer?

I'm sad for Steven and for all the other software engineers who tell similar stories.

I don't have math or numbers on this- does anyone?- but I can tell from personal experience that just about every time some software engineer my age becomes mortally ill, it's brain cancer. There is something unstudied about what we do that causes problems.

Personally, I had my biggest scare a couple years ago while I was working on a deeply nested, recursive algorithm. Trying to keep the whole thing in my head caused me to stay awake at night. Eventually, I had a fainting spell at a sushi bar, an ambulance was called, and ultimately the doctor thought I'd had a a massive heart attack.

This didn't turn out to be true, thank God, and they never found the biological cause. But I swear to this day that it was the algorithm gnawing on my brain. I don't know that I've been the same engineer since.

There's a terrible risk in our business and no one is researching it. I almost feel like we software engineers are like 3 pack a day smokers before enough science and research was done to prove to the public that smoking causes cancer.

Software engineering can cause brain cancer.

Trying to charge people for carpooling, something we've traditionally done for free. The "sharing economy" isn't about sharing- it's about monetizing free things and taking a cut.

This is not in any way improving humanity. It's a step backwards.

Great article and observations. It's always good to see what this field looks like from a newbies' eyes.

If it only it were so simple as keeping a small tool set and a dev team committed to it. You can certainly build a business from scratch with a small toolset. But as the business adapts to customers, you always start to find things that customers want that the tools do not support. In initial dev, you don't necessarily care, but when you're live, it's better to implement than say 'no' to executive management and sales in most (not all) cases.

Once you modify the tools a bit to support the unique business, you're no longer able to keep new developers focused on a small toolset, because you've customized. New devs may not agree and may look for ways to work around the customizations. Soon, you have a unique codebase that is valuable- central- to the business, and your changes have crept in to the point that off-the-shelf devs and tools and upgrades don't work.

Now you're in maintenance mode. Code schools don't teach maintenance, but it is the lifeblood of the software business. Developers avoid maintenance jobs. They try to find new, greenfield work. That's why we end up with so many disposable business models, 3 year dev-to-acquisition cycles, and ridiculous amounts of abandoned code.

Maintenance is hard. Much harder than development. But it's much more important. Anyone can launch an app that builds a business. Not everyone can adapt and grow that business with code changes that require getting out of the dev comfort zone.

Code schools don't teach this because they don't want to expose aspiring coders who just want to get rich to the grimy dirty details of a real profession. But ask yourself this- would we have cars and highways if all we trained were new car designers (not mechanics or road builders)?