Slashdot Mirror
Ask Slashdot: What Do You Wish You'd Known Starting Out As a Programmer?
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?
What Do You Wish You'd Known Starting Out As a Programmer?
How to program, I guess.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
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
Peace, or Not?
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.
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.
I write sci-fi for metalheads
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.
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.
"The wisdom of the Patriarchs was that they *knew* they were fools." --Master Foo
Project management, specifically the importance of not being a bottleneck.
Finding God in a Dog
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.
You save only 59 seconds over 8 miles by going 75 instead of 65. Do you really have to pass that guy? Do the Math!
That people who use spaces for indentation are just WRONG. :)
I like you, Stuart. You're not like everyone else, here, at Slashdot.
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.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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!
Political correctness is really just herd psychology pushed by insecure people who desperately seek social conformity.
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.
File under 'M' for 'Manic ranting'
Or just the proper applications of unit and regression tests.
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.
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.
How to Win Friends and Influence People
this signature has been removed due to a DMCA takedown notice
put every god damn penny you can into a 401k.
Oh, you mean programming wise?
The Kruger Dunning explains most post on
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.
Mad Software: Rantings on Developing So
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 handle that one correctly.
Don't disappoint your bird dog. Go to the range.
This Programmer Competency Matrix has been instrumental in helping me "know what I don't know".
Yes, instead of looking for a great job, create great jobs for people.
Website Just Down For Me? Find out
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 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). 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 is awesome.
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.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
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% of the drudge work out of the way immediately, leaving me to actually learn Java.
1) Screw software, hardware is where it's at.
2) Hard topics pay well: DSP, information theory, crypto, information coding, etc.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
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 the nuts and bolts of code standards, defensive programming, code hygiene, technical debt, refactoring, and at a higher level, revision control, automatic builds, code review, and static analysis are considered best practices by some, but are nowhere near ubiquitous.
It may not be an unwillingness as much as growing pains, or that the field lacks a requirement for a P.E. certification that can be used to push back on unreasonable business pressures. Don't assume that you're entering or working in a field that has a well-established set of rules that you can rely on, and if your gut tells you that cult of personality is overriding a technically-based meritocracy, that may very well be the case. The process of software creation seems to still be changing, evolving, maturing.
You can still learn those best practices and apply whichever of them you have the power to in your own environment -- just don't assume everybody will abide by them, or even agree as to what they are.
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!
This would have been so useful to know how to use back in the olden days of yore.
What do the kids use these days for the various languages?
Reusability and modularization - those would've saved me a lot of time.
I wish i had known that i knew nothing ;-). Because at that time i thought i knew everything...
I'd be having a threesome with my younger self and older self
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.
Build it, and they will come^Hplain.
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.
Welcome to the Panopticon. Used to be a prison, now it's your home.
Become a plumber. - better hours, comparable pay, healthier lifestyle, & your job will never be off-shored or out-sourced,
Given that snydeq wrote the opposite of what we think he meant, he might not understand your (Anonymous Coward's) correction. After all illiteracy often includes an inability to understand what is written and not merely an inability to express one's self in writing.
snydeq wrote: "I simply loved to code and could have cared less about my 'career' ..." That means snydeq cared more than he could have cared. If he instead wrote: "I simply loved to code and could not have cared less about my 'career' ...", that would mean he did not care at all.
That it would have been better to open up a donut shop instead.
Hope is the currency of fools
I'm one of the most naturally talented programmers I've ever met. My code is extremely good. I won many competitions. I scored near perfectly on knowledge and practical exams with an IT staffing company and beat almost all their other employes. AND YET nobody will hire someone with two 2 year degrees. That would have been nice to know. I got a job as CIO of a medium sized company at 24 years old so it worked out but I would have had more options ignoring programming and just getting more server management, networking, and support training.
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.
I don't want to achieve immortality through my work. I want to achieve it by not dying. - Woody Allen
It's "could NOT care less", you stupid, American cretin...
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)
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
If you mean the quality of code that gets churned by your average coder, then yes, it is just like plumbing.
Of course! And you are above average, I take it.
See, this is the type of attitude that makes me really hate this profession.
My code has been called brilliant - even genius - and the same code has been called crap by a different person.
Personally, I would never want to work with or for the parent.
Does the code work as designed?
Is it easily readable and maintainable?
If yes to both then STFU and go back to your Cheetos and Coke.
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.
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.
...I'd known that to be hired by IBM meant you first had to be trained by IBM. Would have saved me four years of college.
When I started programming, I wish I'd known that I would hate doing it as anything other than a hobby. I wasted a lot of my college years studying something I'll never used in a job.
I wish I knew that one day the Kim Kardashian iPhone app would be number 1 in the App Store and based on sales it is on track to make 200 million dollars
(Yesterday's Business News).
If I knew this, I would make the right decision to join a doomsday cult because the end times are here. Or I would drop out of school and become a gangster.
Fuck it. Engineering or Computer science for 4 miserable years... Not worth it kids!
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.
Or that none of this will really help get you laid?
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...
The Cloud - because you don't care if your apps and data are up in the air.
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.....
Diplomacy Skills and Design Patterns. Those are my two I wished I learned starting out as a young know-nothing.
Since I started learning from my dad in the 70's- I wish someone would have told me how mean and spiteful would come to prevalence as the default behavior. I am glad I began when I was young and had wonderful mentors. I am glad I knew who Don Nelson was as well.
quis custodiet ipsos custodes
Starting in about 2004, I spent a couple years becoming proficient in Perl 5. I used it for everything, from serious web programming to complex Win32 GUI-based applications "compiled" into stand-alone executables using ActiveState. Somehow, though, I allowed myself to remain oblivious to the fact that Perl was headed absolutely nowhere.
Then I decided to look for jobs as a Perl programmer.
It had never occurred to me that programming languages are living, breathing things that can actually die if they don't get enough oxygen. I suddenly realized that my efforts to develop prowess in Perl had actually turned me into a tumbleweed, blowing farther and farther away from any sign of civilization. The solution, of course, was to do what everyone else did: Abandon Perl.
Now I wonder if my current language, Java, is headed for a similar fate...
1) You'll spend as much or more time fixing code than you do writing it. Therefore, anything you can do early in the process to reduce those is time well spent, even though it may seem like a waste of time:
- Single-step through every line of newly written code
- Do a little personal code review of all code you write
- Develop module tests as you write code
- Test every line of code in some way, either informally or formally.
- Write comments and documentation, even if just for your own benefit. Your future self may not understand what you've done as well as your present self does.
- Make changes to working code sparingly, and take steps to make sure that every change is for the better. (See above.)
2) Write code in small pieces, get the pieces working well, and stitch them together. Don't write something giant all at once that may never work.
3) Approach debugging on a data-driven basis. Most problems can be solved best by instrumenting what's happening in some way, e.g., via a debugger or a simulation. Though the trial-and-error method often is appealing for instant gratification, it's usually inefficient.
4) Read a few very good books: "Writing Solid Code", "Code Complete", "The Mythical Man Month", "The C Programming Language".
5) Learn several languages, including Python. Every language you learn makes you better at the other languages you already know.
Don't be a victim. Learn the rule. Read "MBA for Dummies" :-)
Code more, obsess less.
That is, just crank out more code and learn from mistakes rather than always trying to make it perfect the first time and never finishing.
Also, not to listen to people who say your idea wont work. Give it a generation or two and you'll have the speed and memory to do it.
-- Senior Software Engineer, Attorney appearance services, locallawyerapp.com.
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).
If you want to do only the things that you enjoy doing ... start your own business, and be successful enough that you can hire someone to do the stuff you don't want to do. And that doesn't require having a degree. The degree is just so that you have a sheet of paper from some group vouching that you have some minimal set of skills to be a productive employee.
Build it, and they will come^Hplain.
PHB?
At the same time, I usually failed to pick jobs for the best reason: What will help me progress in my career? Sometimes that means taking a job for less money but more responsibility or better opportunities.
IMMEDIATE and urgent RED FLAG!
No I don't think that this job is a "career opportunity leading to rapid advancement". I will not work for "exposure".
Fuck you, pay me!
6. Work more than 40 hours per week. ... If the only time you learn something is on your boss's dime, then prepare to have your options limited -- your boss isn't going to train you...
What kind of class-warfare propaganda bullshit is this? Hey, I get the sentiment, having a home/hobby project where you code in your spare time does indeed help turn you into a better programmer. But the way he spins it... dude, what the hell?
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.
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
Why... regular expressions of course! I could have saved myself endless hours of dumbfounded confusion!
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.
Proverbs 21:19
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.
putting the 'B' in LGBTQ+
Yup, same here. I never *chose* to be a programmer, I wanted to work on AI/robotics. It just sorta happened, and I got out of that field *fast*.
IT in general - just - kids, don't do it. When you do good work, they want to lay you off or outsource you. When you screw up, everyone hates you.
My kids saw my work and decided to go into autos and welding. Says it all right there.
An operating system should be like a light switch... simple, effective, easy to use, and designed for everyone.
Comment removed based on user account deletion
Its not like kollege where yu write a program, make it work, and then are finished.
In a business a lot of other thing go on:
planning
specifications
coding
check into codebase
TESTING
WRITING TESTS
fixing bugs
tracking bugs in a databse
selling the idea
selling the software
supporting the customer
managing all the people that do this
learning new technology
teaching the new people
maintaining the computers to some degree
All this stuff occurs whether you are a single consultant, part of a small startup company, or part of a mega-software company.
In a small software company you probably have the mode overall hours devoted to coding.
A single-consultant is probably spending lots of time on non-coding aspects above.
A large company has specialists handling things like selling and testing. The fraction of everybodies hours devoted to coding may be rather small, less than 20%.
Learn how to use the debugger as soon as possible!
The CS program at the school I went to for a degree in 1997 waited until the 4th year of the program to introduce us to 'gdb' for C and C++ programming.
I probably would be married [at least once] if they taught debugging techniques in the first year. (I realized that I had too many late night coding sessions for no good reason -- programming became too easy after using a debugger properly)
My uncle worked for Burroughs and then Sperry/Univac as an EE/Computer Engineer. With layoffs looming and managers telling him he should take the early retirement package, he refused as he wanted to work, enjoyed working, and felt he was too young to retire. Next thing he knows, he's laid off, lost the golden parachute and, being disabled, was unable to find a real job before he did actually retire. Sperry screwed him but good.
As long as your company sells it, it will come back to haunt you 10, 20 years later. When you are bored as hell with it. Or forgotten everything about it. Hardware changes, OS'es change, and old shit breaks sometimes.
Perhaps the main remedy is to change compnaies somtimes. Then somoen else fixes your old stuff. Or you fix someone elses old stuff.
Either love programming for it's own sake or find a different job.
Nobody sees a software engineer as a true engineer, so you'll spend a lot of time dealing with stupid people who insist they know how to do your job better than you. These include (but are not limited to); bosses, managers, HR people, sales & marketing people, customers, clients, business partners (atleast their non-IT staff).
Unless you thoroughly enjoy programming, you'll quickly burn out.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Back in the day (80's 8-bit micros) I started on BASIC and Z80 machine code followed by a little FORTH.
The one thing I really wish I'd known about - or understood - was what LISP really is. It was often described in the popular computing press as a language "for processing lists."
How very wrong. The reality is so much better.
I didn't seriously look at the lisp family of languages until about 6 or 7 years ago. I really wish I'd looked 25 years sooner.
Stick Men
I mis-posted. You are right.
I was talking about the .com bubble.
I typed .net instead of .com because I am a fool.
... that canned packages were going to do all that for me.
It little behooves the best of us to comment on the rest of us.
I always wanted to be a programmer so I could while away the night, hacking away at solutions to problems that interested me. Now I find myself in a career mired by paperwork, delays, and clueless management. I wish I would've known what the real world was like before I started -- perhaps I'd have taken up that writing career instead. (Who's kidding who... it's just as bad, if not worse.)
My reality check bounced.
I think it's very valuable to be at least a little bit familiar with C, so you understand what the interpreter or .NET runtime is doing behind the scenes, and something like a .NET language for a bigger view. For example, I didn't really "get" objects until I worked on VB for a while. Graphical objects like text boxes and buttons are clearly objects which have their own properties, events, and methods. Until then, I thought of objects as little more than function libraries. Working in C or something else low level, sometimes you can't see the forest for the trees.
On the other hand, people who only know very high level, highly abstracted, languages routinely do stuff that's obviously incredibly stupid - obvious to the person who can roughly translate that C# into ansi C. If you don't know what the runtime is doing behind the scenes, you don't realize that while you could access the disk 1,000 times, you're instead accessing it 1,000^2 times (1,000,000).
Not that everyone should be GOOD at C or assembly and good at Java or .NET, but being familiar enough with both high and low level will make you much better at whichever you prefer.
Software Engineering is the only profession where your perceived value decreases with age.
If I'd chosen, Medicine (Human,Veterinary), Law, Accountancy, Business, etc the older I'd got the more valuable I'd be.
If I'd chosen any other type of engineering the same would apply.
Who's bridge would you want to cross - the civil engineering grads or the guy who's been doing it 20+ years?
There's a real problem with the non-technical populations perception of the value in software because it's beyond their comprehension.
Why would I hire a middle aged guy to write my App when I can pay a student party money to write me one?
Sure, why not get a law student to handle your divorce or your property purchase too?
Then add on top of that the universal nature of software.
You wouldn't get a guy in China or India, at $1 an hour, to advise or complete your tax returns would you?
However you'd happy pay him that to setup a bespoke website with web apps.
I wish I had learned C as my first language instead of Visual Basic. It would have saved me years of headaches.
This signature has Super Cow Powers
One of my biggest advances as a programmer has been writing unit tests for everything and the associated decoupling of code required to make unit tests for everything actually work well. They reveal weaknesses in your design early on, before fixing them is too bad, encourage reusable code, encourage you to keep your design simple and increase the degree of certainty you have when you deploy something. I haven't quite jumped on the test-first bandwagon yet, but I'll write a class and then write its unit test. If the unit test reveals that more functionality is needed or that I need to change something, I do it then.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Mind you, I learned how to code back in the days when CP/M ruled the universe.
-- Tigger warning: This post may contain tiggers! --
At least you don't have meetings.
Meetings are a giant time suck.
-- Tigger warning: This post may contain tiggers! --
A lot of people obsess over making new wheels. They'd be far better off it they wrote a decent object library to do wheels once, maintain it, and spend far more time getting the engine to push the wheel.
Wheels are wheels. You don't need to make a new one every time, unless you're writing the core Wheel program. Spend your time on the stuff that matters, not the inner mechanisms of the windshield washing blade, use someone else's windshield washing blade.
-- Tigger warning: This post may contain tiggers! --
1.) Comment, comment, comment. If in doubt about comments, comment. 2.) Learn to say no. If you're working on a team where you're constantly asked to introduce new features without extending a deadline, don't be afraid to say no. 3.) Learn to write testable code and unit tests early on. The sheer number of hours in my career I could have saved had I learned early to write testable code is unfathomable.
I prefer not to be elbow deep in actual shit.
The Kruger Dunning explains most post on
The other thing I wish I had known earlier as a programmer is that while open source is nice for developing skillsets, it's also nice to make a few bucks with the things I create. Had I been a little more business minded in my early years as a programmer, I would have been a lot richer, a lot sooner. This also relates back to mentoring. As a young programmer, it's very important to seek out and work with grizzly old programmers who have been where you are, and experienced the things you might be trying to figure out right now. Personally, I didn't even realize I needed mentors until about five years in. I should have looked for them earlier.
This signature has Super Cow Powers
Be good at what you do, but don't forget to take care of yourself.
Success and happiness depends on realizing work is not a meritocracy. Your co-workers and customers have their own agendas. You can laugh about it or cry about it, but accept it and decide how you'll make your way. If you choose a path of integrity, you at least have pride when you lose. But expect that co-workers lacking integrity will learn to destroy you, and others will learn to depend on you, particularly if you are any good. Neither will support you.
Overall, luck is random, which means the more you try, the luckier you'll be. If you learn your lessons and cut your losses, it'll be a net gain. But there's little point in random bouts of luck. The only way to become something is to imagine that and start doing it -- which means giving up good things that don't help, and not devoting yourself to someone else's cause.
And if you are successful at any scale, you'll be leveraging many things - a social network, opportunities/timing, investments and investors - that require constant maintenance and leave few degrees of freedom.
(There's no rest for the wicked, and the righteous don't need it.)
Programmers tend to stay naive about this because they trained in rationality, code all day, interact mainly with other coders, and believe their work evaluations couched in pseudo-objective, individualistic measures and backed by money. But to others in the business (yes, even at Google), coders are monkeys at a keyboard, and the only question is how many you need.
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 inversely periods of time where work dries up completely (i.e., no pay).
comparable pay
In 3 years as programmer my income has surpassed the highest paid, 30-year veteran, Journeyman plumber at my previous place of employment. And good luck finding an employer that offers 401K contribution matching.
healthier lifestyle
Tell that to my great grandfather, my grandfather, several uncles, brother, and my father - all plumbers with severe back issues starting early in their careers and worsening to a chronic state in old age.
While I'm sure that poor pay and shitty hours are a reality for some programmers, they usually have a choice whether they realize it or not. Most blue collar professions don't provide you the option to quit and find better conditions in the same field elsewhere.
If you're overworked, underpaid, and unhealthy that is on you to do something about it.
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
I do not fail; I succeed at finding out what does not work.
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 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.
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.
Well.. maybe. Or Maybe not. But Definitely not sort of.
Sometimes doing things the insane way is the sanest method available.
Let me explain:
A new programmer will look for a method to transform one object to another another; a new programmer will write a method to transform some bytes into some other bytes.
A (slightly more seasoned) programmer will realize that even though you are using a higher-level language, someone inevitably said "f*ck it" at some point, and built byte arrays[] and so on into the various namespaces / classes, and that it's more of a search for the right namespace than inventing the wheel for the 5000th time. From the usual 'sane' standpoint, resorting the byte[] arrays in a high level language kind of defeats the purpose of using a high level language, and yet, somehow, between the hours of 1-3 AM, it makes perfect sense for a high level language to be filled with all these nitty gritty options.
You wish you had always known "how to design a solution on my own time before I code a solution on company time"? Why?
The more general principle is that you should design before you code... or rather: experiment, research, understand, test, analyse THEN design THEN code, then RE-write that code. It's the oppose to the write-once philosophy, if the task deserves it, then you should try to fully understand the problem before designing and coding for it.
But often with less engineering orientated programming you don't get time explicitly allocated for doing those things... so when you want to do a good job and are asked to write a moderately complex piece of software, you know that to save time overall and create a body of code that isn't going to cause you a headache to maintain later; you will have to invest some of your own time to think about it.
And the more cynical people here will say, "hey you don't get paid for that, programmers work too long hours blah blah blah" but you know what... it's worth it, because you become a better programmer, you learn more interesting things, you become better at thinking about problems and engineering solutions... if you aren't interested in those things then why are you coding at all, there are easier ways to make a living.
They all suck in their own peculiar ways.
In fact, "All current languages have faults. There is no language that's suitable for all situations at the present time" is arguably something that aspiring programmers should learn at the outset.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
1 ) Make liberal use of saves, back-ups and version control check-ins. Disk space is cheap, and having incremental versions can be a life-saver in case things go awry.
2 ) When given an existing piece of software to modify or maintain, do not assume that the previous authors had any clue about what they were doing, or that they followed good coding practices. After fully analyzing the code, be alert for opportunities to restructure / rewrite portions that will improve maintainability and efficiency and determine if they can be implemented as part of the updates.
3 ) Comment heavily. At the very least, add comments for each functional block to help identify their purpose, expected inputs and outputs. Always add comments for non-obvious line entries. Also make sure to clearly comment any debug / trouble-shooting code that is added to make it easy to remove later.
4 ) Today's coding choices may last forever. Once implemented and released, it becomes significantly harder to make changes later. Make sure that proper architecting and design work is done up front way before any code gets written.
5 ) If you don't like it, get out. One of my professor's used this phrase a lot, and my experience in engineering has led me to agree with it. If you don't like coding those lame exercises in software classes, chances are you won't like coding in the real world either. Passionate and motivated programmers tend to produce better results. If you don't enjoy writing software, find something else that you do like instead.
bingo
the whole idea that having some random, abstractly "difficult" class that is difficult b/c it is full of pointless busy work, and that class will test who will be a good engineer...the whole notion is foolish and ruining tech
the idea of "weeding out" is fine...but making a class antagonistic expressly for that purpose just **wastes students time** ...you 'weed out' by the admissions process
i really believe this 'weeding out' error has made a mark on the tech industry...it has significantly contributed to the hostile, alienating environment of tech work
Thank you Dave Raggett
I'm not sure what your point is.
File under 'M' for 'Manic ranting'
I still end up hand optimizing a lot of code. There are many tasks which are at the limits of current computational capacity, and require a lot of optimization in order to achieve a run time which is acceptable.
That mindset, and the newbies who have no idea how to do it, lead to few people who can do so competently these days, and therefore make it a very valuable skill.
I'm a signature virus. Please copy me to your signature so I can replicate.
There are tons of professions where knowing how to write good code will help you achieve success over the competition. Computer programmer isn't one of them.
How to say "no."
What my market value was, is, and could be in X amount of time.
DLL hell to start with (now finally going away), but the MS platforms have changed so much that given enough time something outside of your application is going to break it as the next fad emerges and the old one is dropped. Packaging as much in as possible and pretending you are developing for a fairly dumb console with hardly anything available instead of relying on what's currently on top of the quicksand is a partial workaround. Developing for an environment that MS does not have control over which sits on top of the OS is a better workaround.
The code groupies you hear about.
Not true. :(
Switch jobs every 3-5 years. VC spread their money over lots of companies. You should do like wise. Falling in love with a company is great but in the the end your a resource to be extracted and disposed of for people with "business acumen". You need to take the same attitude and and make sure the company is in fact giving you your due. Get your equity and get out. If the company is actually showing promise in 3 to 5 year maybe stay but do not ever think the companies success hinges on you being there. It does not. The business end of the business will do everything they can to make sure that is not the case even if it is. Good luck
Wow, that was really interesting. I think I read your entire website! Thanks.
I wish I had known that even if you get a $100K salary, that could still come out to $20/hour or less.
Fresh out of college I was confident that things like GUIs are optional and code generation was a fad, and that the latest versions of frameworks weren't worth using until they'd been released for at least a year (I probably read too much /.). After some time I found that laboriously written code that would later be rendered broken or inferior when technology advanced, and new tools could automate what my code did, but often quicker, better, or in a more maintainable way. People around me were frequently mentioning new tools, but I was too hard-headed to listen. I could have saved myself tons of work on code that later became a burden to the organization. Don't be afraid to experiment with tools and techniques that will save you time, you don't need to have control of everything.
Millions long for immortality who do not know what to do with themselves on a rainy Sunday afternoon. -- Susan Ertz
Slashdot.
Casteism
less about programming-language-x and more about processes and stuff like collaboration and version control. Imho people should learn that asap, preferably even before they start developing "more serious stuff" (i.e. anything more than "hello world").
1) Programming students are told to write clearly, because clear code is easier to maintain. True. But students should also be taught another advantage of clear code - it cuts down on the chance of mistakes in your code.
For example,
++i;
if (i > 2) {...}
is easier to read than
if (++i > 2) {...}
Before you promote your code, you and your code reviewers will find more mistakes in it, if it's clear.
2) Students should be taught to balance time spent planning vs. time spent coding.
Sometimes beginners think planning is a waste of time, and they jump into coding too soon. They need to be taught to figure out the user experience, classes, etc. first.
But on the other hand, they shouldn't spend so much time getting the user experience just right, that they won't be able to finish coding and testing on time.