Forgot your password?
typodupeerror
Programming

Ask Slashdot: What Do You Wish You'd Known Starting Out As a Programmer? 548

Posted by Soulskill
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?
This discussion has been archived. No new comments can be posted.

Ask Slashdot: What Do You Wish You'd Known Starting Out As a Programmer?

Comments Filter:
  • by amicusNYCL (1538833) on Thursday August 21, 2014 @01:32PM (#47722015)

    What Do You Wish You'd Known Starting Out As a Programmer?

    How to program, I guess.

    • Re:What to know (Score:5, Insightful)

      by ObsessiveMathsFreak (773371) <obsessivemathsfreakNO@SPAMeircom.net> on Thursday August 21, 2014 @05:07PM (#47723939) Homepage Journal

      Your outdated "value-adding" "service provding" skills are so 20th century. 21st century careerism is about networking. Networking. Networking. Netowrking.

      Look at item number one on TFAs list.

      1. Take names. ...

      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."

      No wonder so many programmers go into management.

  • by jjn1056 (85209) <jjn1056&yahoo,com> on Thursday August 21, 2014 @01:32PM (#47722017) Homepage Journal

    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

  • by Anonymous Coward on Thursday August 21, 2014 @01:32PM (#47722023)

    On my CS track, you start with C++, learn data structures and algorithms, and then learn assembly on a 68k.

    I can't think of a better way to discourage someone from learning how to code.

  • by Lilith's Heart-shape (1224784) on Thursday August 21, 2014 @01:35PM (#47722039) Homepage
    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.
    • Came here to say this!

      And it sucks everywhere except NYC/SF/Austin/Boston

      I probably should have gone into some kind of engineering.

      • by pscottdv (676889)

        Chicago is pretty good.

      • Can you get manage a 40 hour workweek as a coder in NYC/SF/Austin/Boston or Chicago (as another reply mentioned)?
      • by slashdice (3722985) on Thursday August 21, 2014 @02:04PM (#47722371)
        SF still sucks, depending on which side of the glory hole you sit.
    • by MAXOMENOS (9802) <maxomai@g[ ]l.com ['mai' in gap]> on Thursday August 21, 2014 @01:43PM (#47722117) Homepage
      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."
    • by roman_mir (125474) on Thursday August 21, 2014 @01:43PM (#47722119) Homepage Journal

      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.

      • by NoImNotNineVolt (832851) on Thursday August 21, 2014 @02:14PM (#47722489) Homepage
        I was a cashier at the local supermarket in high school. Of course, all supermarkets are unionized. Do you have any idea how hard it was to get this job?

        Not hard. I applied. I was working that same week. If the union was a barrier to entry, it wasn't one big enough for me to have noticed. What the fuck are you talking about?
    • by sinij (911942) on Thursday August 21, 2014 @01:44PM (#47722121) Journal

      If you mean the quality of code that gets churned by your average coder, then yes, it is just like plumbing.

      • by Rinikusu (28164) on Thursday August 21, 2014 @01:50PM (#47722205)

        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.

        • I write SF, but it's hard to let go and not give a shit at my day job because I'm still enough of a Randroid to want to give people their money's worth.
          • by TXG1112 (456055) on Thursday August 21, 2014 @04:41PM (#47723721) Homepage Journal

            enough of a Randroid to want to give people their money's worth.

            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.

    • by Khashishi (775369) on Thursday August 21, 2014 @02:03PM (#47722357) Journal

      It's not unionized because conditions aren't bad enough to warrant it, as much as programmers like to complain.

      • 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.
  • 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.
  • History (Score:5, Insightful)

    by TechNeilogy (2948399) on Thursday August 21, 2014 @01:40PM (#47722083)
    I would have studied more about the history of computers and computer science. It would have kept me from re-making so many mistakes and re-inventing so many wheels.
  • Where to begin (Score:5, Interesting)

    by MAXOMENOS (9802) <maxomai@g[ ]l.com ['mai' in gap]> on Thursday August 21, 2014 @01:40PM (#47722087) Homepage
    • Project management, specifically the importance of not being a bottleneck.

    • How to design a solution on my own time before I code a solution on company time.
    • Differential diagnosis of bugs (see #2 of the link above --- although I learned this skill later in graduate school and have applied it multiple times since.)
    • Code for readability and correctness first, efficiency later. Code that is "too clever" will never be maintained (except by you).
    • I really enjoy programming as a way of automating tasks and not for other reasons --- which makes me better as a systems administrator than as a software developer.
    • Re:Where to begin (Score:5, Insightful)

      by preaction (1526109) on Thursday August 21, 2014 @01:48PM (#47722179)

      • How to design a solution on my own time before I code a solution on company time.

      Though I inevitably unconsciously think about work code during non-work time, I will never consciously spend time thinking about or working on work code during non-work time.

      They are paying for my brain, they can pay me to sit and think for a while. The actual typing of code is not what programming is.

  • How to troubleshoot. (Score:5, Informative)

    by darylb (10898) on Thursday August 21, 2014 @01:40PM (#47722091)

    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.

  • How to write code (Score:5, Insightful)

    by DudeTheMath (522264) on Thursday August 21, 2014 @01:41PM (#47722093) Homepage

    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.

    • by Jason Levine (196982) on Thursday August 21, 2014 @02:06PM (#47722381)

      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.

  • by NecroPuppy (222648) on Thursday August 21, 2014 @01:43PM (#47722113) Homepage

    That people who use spaces for indentation are just WRONG. :)

    • Re:Quite simply... (Score:5, Insightful)

      by Wraithlyn (133796) on Thursday August 21, 2014 @03:38PM (#47723247)

      OK, I'll bite. :)

      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 wished I had known about SmallTalk and started with it rather soon.

    Perhaps I should have finished my studies quicker and made a PhD and should have went into research instead of programming in the industries.

  • Hindsight is 20/20 (Score:5, Insightful)

    by MagickalMyst (1003128) on Thursday August 21, 2014 @01:45PM (#47722141)
    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!
  • by mark-t (151149) <markt@@@lynx...bc...ca> on Thursday August 21, 2014 @01:47PM (#47722171) Journal
    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.
  • by aeschinesthesocratic (1359449) on Thursday August 21, 2014 @01:48PM (#47722177)
    Or just the proper applications of unit and regression tests.
  • Grit (Score:5, Insightful)

    by jones_supa (887896) on Thursday August 21, 2014 @01:48PM (#47722183)
    I would have teached him grit. Oh god, how many unfinished little projects I had. Learn to concentrate on one thing and finish it properly. Just keep grinding on it.
  • by ERJ (600451)
    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.
  • by pscottdv (676889) on Thursday August 21, 2014 @01:50PM (#47722203)

    How to Win Friends and Influence People

  • Simple (Score:5, Insightful)

    by geekoid (135745) <dadinportland @ y a hoo.com> on Thursday August 21, 2014 @01:51PM (#47722217) Homepage Journal

    put every god damn penny you can into a 401k.
    Oh, you mean programming wise?

  • 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
  • by Deffexor (230167) on Thursday August 21, 2014 @01:54PM (#47722249)
    This Programmer Competency Matrix [sijinjoseph.com] has been instrumental in helping me "know what I don't know".
    • I like it too, but it's kind of brutal. :) I'd say that even if you land somewhere between level 1 and 2, you're pretty good already. This is how I would interpret it:

      Level 0: Rookie
      Level 1: Competent for many programming jobs
      Level 2: Experienced guy competent for most programming jobs
      Level 3: A true genius competent for the most advanced tasks

    • by Nemyst (1383049) on Thursday August 21, 2014 @02:42PM (#47722811) Homepage
      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.
    • by angel'o'sphere (80593) on Thursday August 21, 2014 @03:19PM (#47723103) Homepage Journal

      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.

  • One Year In (Score:5, Informative)

    by Niris (1443675) on Thursday August 21, 2014 @02:00PM (#47722311)
    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.
  • Two things.... (Score:5, Insightful)

    by bobbied (2522392) on Thursday August 21, 2014 @02:01PM (#47722327)

    1. A copy of the "Mythical Man Month" by Fredrick Brooks and being told to read it.

    2. A set of closing prices for every stock on the NY exchange for the next 20 years with the advice to become an investment banker..

    If #2 isn't possible, then sitting down with somebody who could explain that you get what you negotiate, not what you deserve, so don't settle for what you get.

  • 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

  • 1) Screw software, hardware is where it's at.

    2) Hard topics pay well: DSP, information theory, crypto, information coding, etc.

  • 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.

    Examples of this are that t

  • My lessons (Score:5, Interesting)

    by Rob Hostetter (2908585) on Thursday August 21, 2014 @02:07PM (#47722409)
    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!
  • by idontgno (624372) on Thursday August 21, 2014 @02:13PM (#47722461) Journal

    You can ignore them, in which case you've volunteered for the role of "victim".

    You can make them your full-time job, in which case you're no longer a developer.

    You should find a good defensive middle ground. At least, some situational awareness. Put your head up and look around. And listen.

  • by MondoGordo (2277808) on Thursday August 21, 2014 @02:14PM (#47722485)
    Become a plumber. - better hours, comparable pay, healthier lifestyle, & your job will never be off-shored or out-sourced,
    • Re: (Score:3, Informative)

      by Foolhardly (1773982)
      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

  • by edawstwin (242027) on Thursday August 21, 2014 @02:17PM (#47722527)

    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.

    Also, learn how to be interviewed. It is a very valuable skill.

  • by twdorris (29395) on Thursday August 21, 2014 @02:23PM (#47722605)

    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.

    • Re: (Score:3, Informative)

      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
  • by maliqua (1316471) on Thursday August 21, 2014 @02:24PM (#47722623)

    Find projects you want to do at first to solve problems that will bring you some satisfaction, start simple remove an element of tedium from your day programmatically.

  • by carlhaagen (1021273) on Thursday August 21, 2014 @02:33PM (#47722717)
    I started programming as a kid at the age of 10. This question just doesn't apply to me at all. No such thing as "career" etc. were relevant to me at that point.
  • by obarthelemy (160321) on Thursday August 21, 2014 @02:35PM (#47722755)

    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...

  • by DERoss (1919496) on Thursday August 21, 2014 @02:39PM (#47722783)

    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 some details about my career, see http://www.rossde.com/retired.... [rossde.com].

  • that I'd make way more money as a lawyer :-)
    Then I could spend my time doing computers as a hobby and actually enjoy it.

  • Regular expressions (Score:5, Informative)

    by Drakker (89038) on Thursday August 21, 2014 @03:31PM (#47723183) Homepage Journal

    Why... regular expressions of course! I could have saved myself endless hours of dumbfounded confusion!

  • by wcrowe (94389) on Thursday August 21, 2014 @03:31PM (#47723185)

    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.

  • by cshark (673578) on Thursday August 21, 2014 @04:31PM (#47723657)

    I wish I had learned C as my first language instead of Visual Basic. It would have saved me years of headaches.

  • by msobkow (48369) on Thursday August 21, 2014 @05:09PM (#47723953) Homepage Journal

    My sole advice to myself when I started out would have been to buy Microsoft stock.

    More than buying a house, a car, or anything else, I started out when Microsoft was a penny stock and could have cleaned up big time just by investing a few grand in their stock instead of a car. :P

  • Writing (Score:5, Interesting)

    by Art3x (973401) on Thursday August 21, 2014 @05:12PM (#47723975)

    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].

  • Advise (Score:4, Insightful)

    by Bill, Shooter of Bul (629286) on Thursday August 21, 2014 @05:21PM (#47724039) Journal

    I wish when I was starting out, I knew how idiotic it would sound to tell everyone what I wished I knew when I was starting out. Cause, man, does it sound stupid.

    Come children, let me pretend to be wise by telling your really obvious things I was not aware of when I was your age.

We don't know one millionth of one percent about anything.

Working...