Posted
by
Soulskillon Thursday August 21, 2014 @01:29PM
from the how-to-program dept.

snydeq writes: Most of us gave little thought to the "career" aspect of programming when starting out, but here we are, battle-hardened by hard-learned lessons, slouching our way through decades at the console, wishing perhaps that we had recognized the long road ahead when we started. What advice might we give to our younger self, or to younger selves coming to programming just now? Andrew C. Oliver offers several insights he gave little thought to when first coding: "Back then, I simply loved to code and could have cared less about my 'career' or about playing well with others. I could have saved myself a ton of trouble if I'd just followed a few simple practices." What are yours?

In five to 10 years, that will all be different and the person who you ignored because they were boring and couldn't help you will be the person who could have won you an important opportunity.

Network! Impress people! Dress right! Booze people up! This is how successful companies are made. You will not attract the rright venture capital with your simple abilities. Most companies won't even use those anyway.

2. Problem solving......

Problem solving is essentially the same thing you learned in abstract in seventh or eighth grade or whenever you learned simple algebra.

See! Look at this! The people this guy is writing for don't even know how to solve problems. They just code stuff nobody really needs -- and they're still successful! You think your ability to analyse and abstract is something all the cool kids will pay for? Think again. Your geek/nerd/hipster/bro-grammer cred wil matter far more.

6. Work more than 40 hours per week.

Profession? You think programming is a profession. Get back on that hamster wheel and like it code monkey. And get some hair dye. First sign of a grey hair or stress line from yellow packs like you and we sack you and hire a fresh young grad to suck into a husk.

5. Think in terms of a career, not a series of jobs.

Translation: "You can either join the fed-money, app-cloud bullshit wagon, or you can learn to love foodstamp lines. Either way, it'll still be a superior outcome to any science-fiction fantasy you imagined programmers were capable of making in a rational universe. The Market wants fart-buttons, not robots, so drink the kool-aid or join the lowest caste of contract workers you, you, you..... Loser."

I think the main thing I'd change is I wish I had started becoming active in the open source community around the tools I commonly use. I spent the first 10 years of my career mostly working on my own, or with a few people on the job and was not connected at all with the greater community. I think if I had done so earlier I'd be a better programmer today

I was the same way. When I started out in web developement, I'd stubbornly insist on building everything myself from scratch. Of course, this meant I was putting a ton of extra effort into each project when I could have been using pre-written components to speed up my development. In addition, my custom code was trickier to support. (Pre-written components from other sources that have hundreds of eyes looking at can be debugged a lot easier than custom code that has one or two pairs of eyes looking at i

I disagree. Learn how to program in a well structured manner that other programmers have some hope of following when they read your code. THEN learn how to juggle memory while programming in a structured manner.

If you haven't written code in C and assembly, you're not yet a computer scientist. But don't start there! Learn addition and subtraction before you learn algebra and learn Java or another learning language before you learn C.

I wasn't a comp-sci major, so I don't know how common they are in that field... but in engineering, you typically have a freshman class that's referred to as the 'weed-out' class.

It's not supposed to be fun. It's supposed to be damned hard, so they can see who's got the fortitude to stick with it.

Not all of life is going to be a cakewalk -- there are going to be times when you really have to knuckle down and study, and it's often better to get it over with early on than spend 3 years towards the degree and then find out that you can't cut it.

I've worked places where 1/2 the time was spent doing the 'other duties as assigned'... and some of 'em really sucked. (paperwork... ick)

Think about it -- an undergrad degree is about you willing to spend 4 potentially productive years to get a sheet of paper. (and in my case, that's all it was... as they neglected to flag in their computer system that I had graduated, so 7 years later, when I needed a transcript, I had to spend many months and threaten to sue to get them to mark me as having graduated

Assembly on a 68000 is easy. In my days, we had to build our own opcodes from rocks, uphill, in the middle of winter. Good thing we had onions on our belt though, because that was the "in" thing back in the olden days....what was I talking about?

I wish I had known to pick a different trade instead of programming. Programming isn't a profession like law or medicine. It's a skilled trade like plumbing, masonry, or electrical work. But unlike plumbers and electricians, programmers aren't smart enough to unionize, and so they get fucked in the ass by management.
If you have to live in the United States, don't become a programmer. There are better ways to earn a living.

Minneapolis here. Getting 40 hours or keeping to 40 hours (whichever is your issue) is not a problem. Wages easily put you in a high standard of living. Of course cost of living is much lower here than any of the cities mentioned but that's part of the appeal of living here... more bang for your buck. Well that and everything else.

If you really think it sucks everywhere that is not NYC/SF/Austin/Boston then you need to pay more attention.

"programmers aren't smart enough to unionize" are you kidding me? To be clear I am not anti-union by any means but for my job not on your life. I'm sure life is different in the valley or big code farms elsewhere but honestly I am better equipped to negotiate as an individual than within a group. The world changes and as development becomes more commoditized this situation may change as well but I don't see that anywhere in the near future. (read my employment lifetime) when my threat as an individual to walk away carries as much weight as a union making the same threat there is no perk to the tradeoffs.

Classically speaking, unions existed to drive up benefits through threat of strikes or walkouts. In the 20's and 30's, unions were responsible for the 40 hours workweek, Saturdays off, and a living wage -- by preventing things like random firings and unpaid work (see 80 hour work weeks in the game industry).

To be clear, if individuals were better at negotiating wages, we'd see a rise in salary in the field, but according to statistics [usnews.com] this is quite simply not the case. "Ah, but salary went up from 80K to over 100K you say", to which I agree, but if you adjust for inflation [usinflatio...ulator.com], you'll see that that $80K in 2004 is equivalent to $100K in 2014 (26.1%). In the same period, the tech heavy Nasdaq grew 143% [yahoo.com]. While some of this can be attributed to there being more people employed in the field, I doubt there 2.5x more CS graduates than there were ten years ago.

So while pay is still decent, there's still no rise in salary despite what many consider an obvious shortage in the field. If more CS majors studied those useless fields like "history", we'd have a union and there wouldn't be a bunch of indentured servants [wikipedia.org] known as H1Bs driving wages down (by artificially inflating the labor pool with people who can't quit).

Remember the Mariel boat lift, when Castro got rid of problem people by pushing them off on the US? There were a fair number of them in the Minneapolis area that summer, and my wife found them mildly obnoxious. Then winter came. Keeps the bugs down, also.

Of course, now that I'm getting older, every winter I think about moving.

I work in a unionized software shop. It's awesome during bad times. In good times one is tempted to think it's better in fast-and-furious start-ups, but then one compares one's salaries and benefits and realizes, "no, actually, union shop is still better."

Programmers are smart enough not to unionise, which allows newcomers into the field without these insane artificial barriers of entry.

Unions are barriers to entry into the field to any newcomers, unions are also horrific from point of view of price setting and prevent people who actually excel in the job from making significantly more than those who only coast by. Your complaint is a complaint of somebody who shouldn't have become a programmer in the first place, but also it is a complaint of a horrible person, who wants to prevent others from entering the field freely.

People shouldn't be licensed just to try and make a living, all professional government dictated licenses and participation in various organizations are a huge economic mistake but more importantly they are a huge impediment to individual freedoms.

Of-course unionization is government mandated licensing, show me a union in the USA and I will show you a special class of people protected by government from free market competition.

I do not have 'right wing talking points', I do not fit into your 'right/left' ideology. My belief system is based on a very basic principle of individual freedoms. Individuals are above the collective, the mob cannot have special privileges at the expense of individual rights. A society where a mob can steal rights of an in

"Individuals are above the collective,"That's moronic, and you don't actually believe that even if you think you do. Do you think my right as an individual means I can drive the wrong way down the freeway? dump toxic chemicals into your ground water? cut in front of you in line? PLay music at 140 db at 4 am?

As a child my dad taught me what to know about unions. He was a union stone mason in his youth.

Unions do not foster excellence. If you excel, you make everyone else look bad. My dad was a hard worker. He would get up at 4:00am and be laying brick by 5:00am, and some night had his truck lights on working till 8:00 or 9:00pm.

He said with the union job, you spent 4 hours working and 4 hours doing other things, like dropping your trowel off the top of the building. Then you had to wait for a supervisor to show

Said the commenter who equated being anti-union to being right wing. I programmed/designed/analyzed for an entire career without the need for someone to represent me. I represented myself. If you're smart enough to code for a living, you're smart enough to do the same.

One of the most difficult things I've had to come to accept as a developer is: If you see a 'clever' way to solve something, STOP. The sad fact is most programmers work on programming teams and you need to absolutely view yourself as expendable. Embrace mediocrity and find another outlet for your creativity. This could be personal projects outside of the workplace, or other hobbies altogether.

Oh the irony.... Your individual contributions have negative value if they cannot be used and leveraged by the entire project/team. No one is an island. Software development is a team sport and there is nothing more useless than a cowboy who doesn't believe they have to follow standard process and methods.

Is there a threshold value at which conditions do become bad enough to warrant organization? Private-sector unionization is on life-support, and the public sector isn't much better. Meanwhile, wages for the average worker in constant dollars have stagnated while prices and corporate profits continually increase. It's not like the government gives a shit about us, so maybe it's time we banded together and started looking out for ourselves and each other.

Get out of my trade. Unions are not your friends. I've watched as union workers fucked me over at trade shows. If you feel that unionizing is what you need, then I submit that, as a developer, you aren't capable enough keep a real job.

My Dues, 30 a month.I get 6 weeks vacation, great sick time, and fantastic benefits.I make 6 figures.

I work 4 tens, any after hours work is billable, being on call is billable. If I give a profession opinion or fact I can't be fired is it happen to be contrary to what some VP wants. Yes, I was fired for explaining why something wasn't possible to a VP. With facts and number and even maths. Yes, I was polite. Hell, once I was reprimanded for putting people in the wrong order in a cc in an email when I worked in the financial sector.

Working 40 is the minority of programmers schedule.

"That's ignoring the risk of the union making it hard to get rid of the people who sincerely need to go,"I seen people let go. There is a process here, and it's a reasonable one. Warning, write up, write up with correction plan, fired.It prevents people for getting fired for political reasons, and it also lets people know when their performance has dropped.As a side note, I got a warning for my performance dropping. Since I normally evaluated as high as possible for my work, this lead e to finding out I was suffering from depression.I've seen people join the union and think it's like the urban myth of the union. They don't last long.

I would have saved myself a lot of trouble if I had looked at job postings to see what was in demand and what was not.
I'm also going to suggest at least an associates degree. If you have a master's, you get much more interesting projects to work on.
Some people look at degrees and some people give technical interviews. A degree isn't mandatory, but you do get exposed to standards and how people expect your code to look, function, etc.

Knowing how to troubleshoot systems -- whether it's code, or things like cars and other physical machines or electrical wiring -- is key. Every programmer will spend time fixing his own code, and has a good chance of spending even more time fixing someone else's. Building the skill to understand complex systems quickly, and to apply fixes that are short of "re-write the whole thing", is essential.

I've been a developer for over 20 years. Maybe 20-25% of my total time is spent writing new functionality. About 35% is fixing bugs (mine and others'), with the remainder spent on process documentation, design, etc.

Write like someone smarter than you will have to fix it ("Who wrote this crap? At least I can tell why he or she did that."), and like someone dumber than you will be adding features ("Bless him or her for making this easy."). You'll be both eventually.

The worst is when you handle old code and think "Who programmed this garbage", only to realize you did years ago.

That's the bad part of growing as a programmer, you look back at your old code and see it as awful since you now know better. (It can also wind up making you think you're a horrible programmer because your old code looks so bad. It doesn't mean you ARE a horrible programmer, though, just that you are growing.)

Oh, yeah, that "someone smarter than you" is often future you! OTOH, I also get to look at the occasional bit of code I wrote ten years ago and think, "Well done, young padawan" (although maybe that means I haven't learned enough yet to know a better way).

The scary thing is, I knew that the crap program I wrote when I started was crap at the time, but I was behind schedule, the requirements had changed 15 times, and I couldn't think of a better way to write it.

In a Perfect World, tabs would indeed be superior to spaces. No question.

But in the Real World, tabs and spaces inevitably get mixed together as multiple people touch a project, and then indentation gets messed up.

Standardizing on spaces helps mitigate this, as everyone sees the exact same thing regardless of editor (whereas tab spacing typically depends on local editor settings). And any editor should be able to "use spaces for tabs" so there is no actual impact on developer effort.

I wish I had known how uninteresting and boring coding could be when working for a corporation. It was the ability to be creative and imaginative that made me fall in love with coding in the early eighties.
Although I still work in IT, I generally don't code for companies anymore.
And somehow coding has miraculously become very interesting once again!

When I first started programming the 6502, back in 1981, I was still in school, and I was manually entering hex opcodes for every machine language program I wanted to create... I was doing this for about 6 months before somebody pointed out that I could use an assembler. I honestly didn't understand what they were talking about until I used one to type in a program that I saw in Nibble magazine. I never looked back. An assembler would have saved me *loads* of time if I had known about it at the beginning.

Sometimes re-writing something just because it uses older technologies or isn't how you would design it is not worth it. Your customers may live by the "quirks" of your system and those code work-arounds may be there for a reason.

Once you've got experience in one language, technology, or area, it can be hard to get out of it. Employers look for people that already have experience in the field. If your first job isn't what you envision yourself doing for the rest of your life, then make efforts to get experience doing the things you want to do. Most any programming experience is worthwhile, but once you feel you've learned what you can, find another job.

Like, perhaps, English. So that he could - after all these years as a professional who types out strings of characters that very specific meaning - understand that when he says "could have cared less about my career," he means "could NOT have cared less about my career."

Maybe he's been working all these years in languages that don't incorporate the concept of "not" or " ! " in evaluating two values. Are there any? I couldn't care less. Grown-ups who communicate or code for a living should be able to hand

I'd argue that while it's a nice table, there's one critical flaw with it: it doesn't matter this much if you don't know everything listed, provided that you can learn it on the spot in a fairly short period of time. For instance, I remember having read about red-black trees or how to treat hashmap collisions and I've already programmed in prolog and so on, but do I remember all those things so well that I could immediately, without looking at a reference, know how to implement/work with them? Hell no. There's way too much to learn in computer science to ever hope knowing everything at once, and claiming that this should be the case (or even, that it is achievable) only serves to demoralize and misguide people.

In my mind, there are two core qualities in computer science (and really, in science in general): being adept at solving problems, and being able to learn new things all the time. The former lets you break down any specific problem in a set of more generic problems for which solutions can be found or designed. The latter means you're able to learn new solutions to problems you may be unfamiliar with.

Unfortunately his list contains a lot of "don't need to know"s and also has lots of flaws.

E.g. "code organization within a file" highest level: each file has a license header... erm, why?

"Defensive Coding"... highest level is bollocks, so is his view on version management, and on IDEs and APIs and the third level of "Scripting" makes me ROFL, 4th level of databases, all level s of "languages with professional experience", or all of "domain knowledge".

Many fields in the matrix look like: "uh, what do I put here?" and then he put some random stuff into it.

E.g. 4th level of "platform internals", erm seriously? I'm an "expert" if I write my own disassembler instead of using the platform provided one? WHY WOULD I DO THAT? Especially as writing a disassembler is not really a challenging task, it belong either into the tools section or the "systems programming" section, at level 2 at max.

Ah, "systems programming" level 4, 'microcode' ROFL. That guy certainly has no idea what microcode actually is. I guess I rather black list that page then keep shaking my head about his strange views.

I just had my one year anniversary as a full time Android developer, and it's insane how much I've learned after leaving school. Luckily there's two older guys (well, one now, the other moved on recently) on my team who are _awesome_ mentors.

1. Pay attention to everything you can in the work place. You may be a client side developer, backend, whatever, but pay attention in every meeting or conversation that you can eavesdrop on. You may not understand everything going on with the teams you don't work in, but just being exposed to their terminology and _looking up what they're talking about_ will get you far. This doesn't go for just development, either - listen to the business and sales guys talk and try to understand your clients and what they need so you can build a great product by anticipating what will work for them before they have to ask.

2. Write a blog. Seriously. I'm the first to admit that I don't really know anything when it comes to development, but I've been actively writing new posts to my blog [blogspot.com] and it forces me to grok whatever I'm writing about. Whatever you're doing, post the code on GitHub so others can read it (mine's here [github.com]). Developers who read peoples code online tend to be awesome about making suggestions and asking questions that make you realize you screwed up without being jackasses about it.

3. If there are tech meetups in your area, go to them. If you're in a decent sized city (I'm in the Denver/Boulder area, which isn't huge, but it's a lot bigger than where I'm originally from) you can find multiple meetup groups related to tech that you're interested in. It's a great way to learn new things and meet a lot of awesome people in your area.

4. If there's hackathons in your area, no matter how small, go to them. You meet awesome people and learn how to work in teams that are different than the one you're in every other day. Plus there's usually free food and beer, so what's not to like about that?

5. Pick up skills that compliment your work area by doing projects that aren't work related. It helps you understand what other teams are doing and how it affects you, plus it just makes you more awesome while keeping down the monotony. As a client side developer, I've been taking a Udacity course on using AppEngine to make backend APIs, and it's been fun.

6. For the love of God, check for null pointers and other kinds of exceptions. You may not catch all of them due to inexperience in spotting them, but that's what senior devs doing code reviews are for. You don't want code going into the wild that crashes, even when data is bad. Getting a call on a Saturday saying something bad is happening is not what you want - the weekends are yours to do whatever you want, not put out fires that could have been avoided.

7. Open source third party libraries are your friend. People way smarter than me have put together some amazing things that we use every day, like Otto and Picasso from Square. Try libraries out in a sample project, and if they will work for what you're doing, give it a shot. If you can make them better in the process, submit a pull request. Like I mentioned earlier, the open source community is awesome and if your pull request isn't up to par, they'll let you know what you can do to fix it.

8. You're going to fail at some things, and it's alright. Fail early, learn what did and didn't work, and try again. Learning from mistakes is how you get better. Along this same line of thought, if you run into a roadblock that you can't figure out yourself via documentation/stepping back and evaluating the problem, StackOverflow [stackoverflow.com] is awesome.

The best tools in a language's ecosystem will free you to actually use the language as intended. With Maven that's certainly the case. Once I committed myself to spending a few days really learning how Maven worked and trying various scenarios with it, I almost cried at how much opportunity cost I'd incurred from sticking with Java IDEs in the past before Maven was built in everywhere. By freeing me from Jar hell, making testing as easy as following a convention and "mvn test" and stuff like that, it got 75

One thing that keeps coming up is the constant inflow of rookie (and intermediate-level) programmers making rookie mistakes. There seems to be an unwillingness to treat software creation, from the academic level onward, as a controllable process towards a working, reliable, secure, usable, maintainable result. It's still being treated from day one as a sandbox with a rigorous theoretical mathematical underpinning, but cowboy coders and fluid design-level rules in the day-to-day.

Here's my advice, been programming for 15 years.
Write comments, one per block of code that does a step, then fill in code. You will then have well commented code, and forced yourself to think through the solution before you begin coding. This saves tons of time by avoiding thought errors before you code.
When hunting a bug, don't just look at what's not working. Instead look at what was most recently changed, even if it seems it couldn't possibly be related. The times I didn't do it this way have cost me many days hunting down a really tricky bug. Sometimes it really is unrelated to recent changes, but not often.
If you are stuck, take a break and do something mindless, like get some water, go to bathroom etc. your subconscious keeps working without the interference of your conscious mind.
Preplan your work a few days ahead if possible. You can avoid many roadblocks by thinking through things ahead of time.
Persistence pays off. I've worked through many "seemingly impossible" tasks, only to find the solution after failing a few times first.
Visualize what the users interaction will be before coding. I like to draw it on paper and pretend to use it. Putting yourself in your users shoes allows you to see what might be difficult to understand. I rarely keep my first design, but since it's just a drawing I'm not invested in it. If you lay it out in software, it's much more tempting to keep a poor design.
Ask a colleague if you are stuck. Often, articulating the problem out loud is sufficient to solve it!

How did this get modded up? These kinds of statements say far more about the person saying them than anything closely resembling reality. I spent nearly 6 years as a plumber before I made the switch to programming and only one of these points has any validity.

better hours

Forget the fact that some summer days you'll wake up at 3:30 AM and head to the job site because by the afternoon it's too hot to throw a shovel (dig holes/trenches). Plumbing is the kind of work with mandatory overtime, 24-hour on-call shifts, AND in

I learned C++ first and just kind of learned various languages and technologies as the need arose, and now I know several languages and my projects have been widely varied. But I noticed that most of my peers who specialized were much more in demand, and therefore pretty much had their pick of jobs, made more money, and had better working conditions. The kind of specialization I'm referring to is learning something that less than ~5% of programmers know, but is still in some demand, and likely to be in demand in ten or twenty years. Or if you pick something that many programmers already know, learn the shit out of that one thing so that there aren't many others that have your level of knowledge in that one thing. In an interview, impressive knowledge of something specific is always better than just adequate knowledge of many things.

I wish I had learned to balance real life with coding life sooner. I used to do the same zillion hour marathons everyone else did at one point or another in their coding careers. I loved the challenge and being the one producing the results. But then, eventually, I realized there's really a LOT more out there than that tiny little challenge/reward cycle. Biking, hiking, sports with friends, whatever. You can easily burn through 10-15 years of your YOUNG life living the code only to realize later when you're not so young any more that there were TONS of things you would have enjoyed doing more. You can make up some of that, but not nearly all.

Amen, and Amen.
I wasted so much of my life meeting meaningless deadlines. When my children were growing up, the wisest advice I gave them was to NOT choose a computer career. (both are Social Workers like their Mom) Sure, It's less money but they will live longer and be much happier with a life worth living.
Programmers come in two shades... Green and Jaded

I work for consulting firms, selling both flesh-by-the-month and fixed-budget custom dev/integration. Here's what I'd like begining devs to know:

1- be presentable. Be clean, pleasant, non-threatening (agreed, that means be lame. Lame is good). You don't *have* to wear a suit and tie (though if you want to move up, you probably should), but at least clean jeans (chinos is much better) and a top with a collar (polo is OK). "Town" shoes are much better than hiking or sport shoes. Needing to express your personality by shocking others is pretty much a dead-end. It's not "look how much you need me that I can bug you by being an ass", it's "look how much I'm sabotaging myself by making my self be a problem".

2- don't be afraid to say "no" and "I don't know". And don't say anything else instead (like "yes" or "this idea/tech sucks"). If your client/boss is asking for unrealistic, impossible stuff, just say so, or at least say you need to check, don't accept. Saying you can't do something, or something is undoable, will hurt you and others a lot less than accepting and then not delivering. Also, "I can't do it" and "it's undoable" are not the same. Maybe you need help from someone else. Maybe you need training.

3- Be proactive. Learn new skills and try to help people around you. You boss mainly. If you spot a problem or a potential sale, say so. Don't make a huge issue out of it, don't get frustrated if it doesn't get top priority, but do point out issues, and if you can, solutions.

4- be patient. Many youngsters have this mental image of where they want to get, and how good they are. You'll probably get there, but not in 6 months. You *will* have to work on nonsensical doomed projects, with idiots as coworkers and bosses. That doesn't prevent you from building skills (technical, personal , organizational), networking and building up your brand...

I manage a team of developers, and I directly hire new developers coming in. One of the things I look for specifically in the interview is "I don't know". Everyone has limits, and everyone needs to acknowledge that they have limits. What's much more important to me is that someone can recognize this and then be able to work around it. The last thing in the world I want is someone telling me they know about something when they really don't, just to appease me.

I went to work for System Development Corporation (SDC) in 1969. SDC was actually the company that established computer programming as being distinct from building computers; before then, the only people programming were the engineers who built the computers. SDC was a good company with good pay and good benefits. Then, SDC sold itself to the Burroughs Corporation, which succeeded in a hostile takeover of Sperry Univac and became Unisys.

At Unisys, we found ourselves in an environment that treated highly experienced technicians and professionals as if we were assembly line workers. Unisys even imposed work rules on us salaried employees that are actually legal only for hourly wage-earners. I should have recognized the abuse sooner than I did and "jumped ship". I could have timed a change for when shortage of software experts made job jumping very profitable. Instead I stuck it out until mass layoffs were very near.

When Burroughs and Sperry Univac merged, the resulting Unisys had more than 120,000 employees. Today, Unisys has less than 25,000.

I must disagree with the replies that indicate programming is poorly paid. I earned sufficient pay that I was able to retire very comfortably before I was 62.

I would suggest that programmers learn how to test rigorously the software they create. This requires that they also write software specifications that are testable, after which they should learn to write formal test procedures. They can then advance into becoming requirements analysts and software test engineers (except in states where "engineer" is a career that requires a license). There are too few analysts and testers, who are often paid much more than programmers. Large computer-based projects are failing because of a lack of clear, objective, and testable specifications. Attempts to put those projects into actual use are disastrous because of a lack of testing.

For the most part I have no regrets over my career choice. I liked it 30 years ago, and I still like it now. I sometimes imagine what it would have been like to be an archaeologist, or a writer (other career choices that appealed to me), but that's just daydreaming. What school did not prepare me for was all the "detective" work involved. A lot of my career has been studying data flows, and re-engineering old processes with no documentation. When I was in school, the emphasis was on writing new applications, not bolting stuff onto old ones.

I'm going to answer this in a different way: what I knew when I started that I think most programmers, and most people, don't. That may sound arrogant, but I keep seeing it every day of my working life.

I wasn't a computer science major or anywhere close: I was a film major and English minor. It was the English that has helped me more than anything learn very quickly certain secrets to programming effectively. And yet it wasn't even the English classes themselves, because a lot of what is fashionable to teach in English [paulgraham.com] is misleading or harmful.

What really happened was a certain approach to writing. It is taught clearly in just a few books, like The Elements of Style and On Writing Well. Reading these books literally changed my life. If I were to try to summarize it, it would be that the goal of writing is to reach the reader as plainly as possible, instead of writing in a flowery, fancy, or important-sounding way. To do that actually is the greatest amount of work. It actually is the opposite of everyone's inclination. Even for professional, longtime writers, it doesn't happen on the first draft or even the seventh draft. It involves adhering to certain non-glamorous principles like using as few words as possible and preferring the short word over the long one. It means putting yourself in the background. In short, in trying to be elegant [paulgraham.com].

It's technically correct because they could, in fact, care less. If they couldn't care less, then they wouldn't be posting about it now would they? (Though I do think the proper "could HARDLY care less" is both more accurate and more descriptive)

Learn principles and techniques. A little theory. Use programming languages to help you learn it but do not obsess over the language. All programming languages suck, just to a greater or lesser extent and some in more interesting ways than others. But basic principles never change.