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.
My parents raised me with a pragmatic approach to life: study hard and then get a job. They should have said: "Study hard, so you can go and live a productive life while changing the world."
Reading server up-time maintenance...
Every day (until I retire) that I would code boring stuff that other people (that can't make up their mind) want.
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!
If I had a time machine I'd tell old me to read even more. I spent a lot of time reading, but not enough since I'm still learning plenty of stuff that makes my life incredibly easier. And then go contribute to some stuff on GitHub instead of writing irrelevant subkloc crap all the time.
But overall I did fairly well. Nice job, old me.
Captcha : reread
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.
Get ready to be told how to do your job by some asshole who read a "How to Program in 24 hours" book and thinks s/he can engineer a solution better than someone with 20 years of experience in the problem space, and then learn how to take the blame when it all falls to shit.
The secret, of course, is to do this while being amiable and competent. As long as my paycheck is deposited on time and as long as that money spends, you can call me a mother-fucking incompetent fuckhead all day long.
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.
Even if there is a big exit, employees get a bonus and founders get paid.
and those are the good ones. They generally don't get in the way enough to prevent success. Then you get one that thinks they know enough to 'fix software development". That's when you're really in trouble.
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'
Newbie programmers these days are completely spoiled with the riches of memory and GHz available. I wish I'd known that a lot of the time spent hand-optimizing my code would be immaterial in a few years time when newer cheaper hardware made the improvements negligible.
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.
Yeah, I've seen this a LOT lately and it bothers me too. It's simple english. To say you could care less about something means literally that! This means that you DO care to some extent and that it could be neglected much further than it is currently.
Why is parent modded down?
Is it a new thing where we say the complete reverse to what we mean?
Is it opposite day already? Or are some people really that dumb?
How to Win Friends and Influence People
this signature has been removed due to a DMCA takedown notice
What a soul sucking career career it really is.
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
**Read their code**.
Talk to them. E-mail them. Chat with them. Download open source software and challenge yourself to hack in a new feature.
I spent a lot of my youth programming in a vacuum. I learned a lot, but I would have learned faster if I didn't re-invent (and fail at re-inventing) many things myself.
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".
...I wish I'd known to spend less time hunched over the keyboard and more time getting laid.
I wish I had known more about contracts and asserted my influence more in negotiating them. Decades ago, good programmers with domain-specific knowledge were hard to find. Verbal promises were easy to come by, as well as easy to break.
Why is parent modded down?
Probably because you're angry. You could have said the same thing without foaming through your mouth.
mo money, mo perks and sales people will buy you drinks at strip clubs
Seriously if you learn VB, Java, and C# all the hipsters want you learn some play language with crazy features that I don't need for 99% of things.
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.
Valid point but the parent was not me. You should not assume that 2 Anons in 1 thread are the same person. Also,I don't know of a mod option that is -1 too angry.
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.
What do I wish I knew before becoming a programmer?
The boss expects you to be in the office every day and be on-time at 8:30 am
"The Boss" isn't a programmer himself
The boss expects code to be documented and expects documentation to be written for the end user.
WTF? I code when it suits me and the code speaks for itself, but the boss can't understand that because he's not a programmer.
And use of that tool depends on the problem space. It's like asking people in a hardware store what they wish they'd known before they started, um, screwing?
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...
To start on a simple machine with assembly, not a powerful machine with BASIC
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.
Proper code architecture / abstraction!
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
That you don't need to waste your time with a degree and crippling debt to break 100K salary.
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
For example, the miniscule font size on the wevsite that published this article causes eyestrain and irritation and is a classic example of web designers not understanding usability.
Stuff like that really.
Programming for a living has burned me out on what I used to love to do on my own time. If I knew then what I know know, I would've dropped out of college, gone to bartender school, and then continued to program as a hobby.
No girls or social life
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
They just throw JS and Ruby together they find on the Internet and hope that it works.
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.
Would have saved lots of wasted time!
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?
Move as quickly and directly as possible to employing other programmers under you. Buy the VP a drink after work and get him to let you hire three other folks. skim $18 an hour on each of them. Spend it on a beautiful... you fill in the blank.
I am a lifelong, head down, hard core coder so don't take this as the advice of some suit.
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.
C++!!! why not A++?
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.....
Man this is dead on. A plumber, mason or electrician can't have their work done remotely for 1/10th the wage either.
Looking back I don't think I would have chosen this profession.
Diplomacy Skills and Design Patterns. Those are my two I wished I learned starting out as a young know-nothing.
What do I wish I'd known, starting out as a programmer by copying out basic programs from my Commodore 16 (yes, 16) programming guide?
That Chemistry might have been a better road.
Don't get me wrong, I've done reasonably well since then in programming. But I wish I'd not been so obsessed with computers in my youth, and concentrated a bit more on science, particularly chemistry.
Would have saved me from going on a YT (Youth Training for non-UK people, if you don't know what it is consider yourself lucky) to do ICT, and I'd have gone to college (16-18 for those outside the UK) instead, and university from there.
Still, the future is still bright. 3D printing and all.
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
I don't get the negative here. I love writing code. I have been happily doing it for 16 years professionally and about 28 in total. It is the best possible thing I could dream of doing. Every single day presents a new challenge. The work is always refreshing. There are always new problems to solve. Technology moves faster than I could possibly hope to keep up. AND the pay is great.
If you don't like it. Don't do it.
I have worked for big co, startups, and myself and they each have their ups and downs. If you are good at what you do you can command your environment. I have successfully avoided promoting to management several times. Why? Because I like to solve problems.
It's like being paid a lot of money to solve puzzles everyday.
With respect to the original article: Who the fuck is this guy? Pick a programming language that will further your career? When I started out, that would have been Cobol or Assembly. He sounds like a manager with his focus on contacts and people skills. Yes, that can help. Yet at the end of the day, if you can't code your way out of a paper bag, nobody is going to hire you. Put the time in to learn how to code!
What I would have liked to have known: This profession sucks! Employers will screw you over every way they can! Most places see programmers as the lowest man on the totem pole. Everything higher is management.
Employers will demand 60 hours a week or you're fired. Then 80 hours a week. Then 100. Look around at your fellow employees. When a cold comes around, and works its way through the staff, who gets sick and for how long? That owner or manager who goes home at 5pm? He's out for a day or two at most. Barely a cough. Your colleague putting in 100+ a week? He can be laid up for weeks. And all too often, he won't get better. He'll die. The chronic sleep deprivation to the point of frequent visual and audible hallucinations coupled with a poor diet and malnutrition (borderline starvation really) from not having time to cook or shop for groceries just wrecks your body's immune system. You go into this profession knowing you're going to have to watch your friends die, and knowing that your turn is coming. That you are going to die half a century before your time.
Dying aside, all that unpaid overtime is hell on relationships. Thinking of having a wife and kids? Thinking of just getting laid someday? Think again!
Salaries may look great on paper, but by the time you factor in all the overtime and vacation you are never allowed to take, you're barely beating minimum wage and those minimum wage folks are paying a lot less in taxes than you are. (They also get daily rest breaks mandated by law that you don't get.)
Stock options: In isolated cases, these can be great! (Just make sure you sell 'em and diversify as soon as possible! Too many people lost their life savings by having it all invested in the company they work for only to get laid off during a downturn.)
In the general case, stock options are worthless. You have a better chance buying lottery tickets. And if they do turn out to be worth something, companies will fire you the day before they vest. Employers will screw you over every way they can!
Employment contracts: Watch out for nasty surprises. You would not believe the things I've seen. Contracts sprung on you after you've accepted the job, often an hour or two after you've started working there. Sometimes even after you've been working there for years. Contracts that may not be legal, but that are backed up by far more legal resources than you could ever afford. Contracts that give the company ownership of everything you do on your own time, crippling your ability to contribute to open source projects, to learn new tools, technologies, and languages, to have a hobby, or to learn the skills you need for your next job. After all, learning new skills and acquiring a better job is not in the employer's best interest. So they're going to do everything they can to prevent that, legal or not. They play dirty! Real dirty! And they're better at it than you are! I've seen phones tapped (violation of state law), refusal to pay paychecks, out-and-out perjury in a court of law, and even when I proved it beyond a shadow of a doubt and the Judge found in my favor businesses still get away with nothing more than a slap on the wrist while I get blackballed! You cannot believe how lopsided everything is! (Just to clarify: Employer did all these things after learning through an illegal phone tap that I had interviewed with another firm. I didn't take the job. In hindsight, perhaps I should have.)
Oh and contracts don't necessarily expire when your employment does. Many of them try to get an extra 2-5 years (or more)
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.
I wish I knew how segment:offset addressing worked in ms-dos 6.22. Then I would have understood why my bitmaps/game looked totally fucked up.
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
While I love programming, as soon as I do it for money for more than a day or two, it gets booooring. There are loads of interesting stuff, neural networks, genetic algorithms, visual processing, etc. etc. But if you are coding for a living, you usually do forms and lists and forms and lists... The sad truth is that most of us don't get exciting IT jobs.
So, after more than 15 years of programming for money, I wish I got another kind of job and only programmed as a hobby.
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.
OK gramps, I'll get off your lawn now.
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
It's probably the skill that has taken me the longest to acquire and I still have not perfected it. I tend to be very outspoken, it's a natural outcome of being highly passionate about my job. It just doesn't have to be in front of the CTO of the company. The relationships with co-workers are more important that even the code.
That said, I was told all this at the beginning of my career and completely didn't get it. Eh, sometimes wisdom only comes with experience.
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.
yeah ... if only someone had shown me hex opcodes! I was nudging protons around with the static charge I could produce from rubbing a balloon on my head briskly. It took well over a dozen popped balloons before I found out about an opcode let alone HCF.
Become a plumber. - better hours, comparable pay, healthier lifestyle, & your job will never be off-shored or out-sourced,
but your back will hate you eventually if you are over 6 foot tall
Really? Living in Germany, on average people working as a plumber (installing and maintaining sewage and water stuffs, is how I translated the word) earn about 75% of programmers on average to a difference of ~500 EUR or 665 USD per month.
Since Americans like to think per year that would be about 8000 USD more per year for the programmer. For a total of 42145 USD on average btw.
You should also take into account the back pain from lifting heavy things and putting and screw etc. and I would say that programmers do have a lot more free time in which they could do exercises that minimise the back pain from sitting in a chair all day.
And how on earth do you figure that plumbers have a healthier lifestyle? What you eat and when you eat is something that is up to you. And being able to pick your exercises as somebody in an office definitely beats having to do heavy lifting or unnatural body postures while installing or maintaining stuff daily.
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.
Learn something really important, e.g. physics, mathematics
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.
Study mathematics, not programming.
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.
Over 39 years, I have make the same mistakes many times. I start typing code as a way of forcing myself to design. I write code in haste, not expecting it to be used much. I optimize for performance unevenly and in many cases unnecessarily. I spend a day mechanically debugging something that could have been deduced in a few minutes. Every bug, every design deficiency, every "oh dear" moment is a small lesson I should have internalized, but rarely did.
Keep a notebook recording what things you did wrong, what you could have done better, risks that paid off better than expected, strengths and weaknesses you see in yourself. Reread it occasionally. You will improve at a far faster rate than your peers.
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.
Especially for meta- topics like this one. Expect a lot of whining and bitching, and don't expect much in the way of wisdom.
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"?
My natural talent and trade is software development, and you can be self employed aka Independent software developer (ISD) and write application(app) code people will want and or become a game developer.
Oh, and how to avoid overuse of if/then with trinaries.
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.
1) computer science
2) programming
3) engineering
4) the role of mathematics in the above 3
Then make an informed choice about what you want to do ...
I wish someone would have told me not to believe the hype around various trendy new programming languages, or amazing new tools with fancy acronyms.
Good solid engineering, science and math seems to stretch a lot farther than the piles of marketingoid speech that surrounds various languages and products.
tl;dh: I wish I knew what a fanboi was and how to recognize when I am one.
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
Get outside, exercise more, learn better posture, learn better snacking habits.
I'm not sure what your point is.
File under 'M' for 'Manic ranting'
I wish, as a 10-year-old, I knew how to assert myself more, to those telling me I was too young and that this product X will be too complicated for you and if anything you should just stick to the BASICs.
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.
I wish someone had turned me on to "The Structure and Interpretation of Computer Programs" earlier on in my career, and of course programming in Scheme/Lisp.
I read it in '85, but it really rocked my world.
Not in my state at least until they give the certification in spanish.
I'd say 75% of the plumbers in my state are latino immigrants, you just need one guy who's legal and speaks English (and writes) to pass the test.
It's been insourced. Just like H1b in software engineering.
How to say "no."
What my market value was, is, and could be in X amount of time.
Programmers are are as catty as hairdressers and real housewives.. if only a haiku in octal format, mocking a back-up script made for good reality tv, if only.
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. :(
**Read their code**.
Talk to them. E-mail them. Chat with them. Download open source software and challenge yourself to hack in a new feature.
I spent a lot of my youth programming in a vacuum. I learned a lot, but I would have learned faster if I didn't re-invent (and fail at re-inventing) many things myself.
I enjoyed reinventing the wheel so to speak. It was how I learned to develop computer programmes. Remember the Lotus 1-2-3 menu styles and other menu styles of the 1980s? I implemented my own library in C to provide window (non-graphical) and menu capability for console applications written to run on computers running Microsoft Disk Operating System.
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.
- No matter how great your software is, inadequate marketing will likely cause it to fail.
It's "could NOT care less", you stupid, American cretin...
You don't even know what the hell you're saying when you say it. Could NOT care less. Idiot.
Or perhaps she's speaking ironically. Is understanding irony a concept that is beyond your capabilities?
I wish I had known that even if you get a $100K salary, that could still come out to $20/hour or less.
I wish I had taken math more seriously in college. It was obvious to me then that mathematics had little to do with programming. You didn't need to know linear algebra or number theory to make a webpage, windows service, or device driver. Why bother? Better to focus on learning stuff I can actually use like Java Web Services.
Now here I am 10 years later and I'm getting interested in artificial intelligence, cryptography, image recognition, etc., and the lack of math is hurting. Most of the interesting stuff in computer science is going to lean heavily on mathematics. Take it seriously.
Dam scrum meetings. Working programmers until the wee hours in the morning. Yeah I wish I knew about that. So I switched gears.
I do other IT tasks to earn a living, my coding.. is for me. I won't write for a company, I worked for enough greedy bastards.. no more.
Ahh.. the good old days.
Now programmers with H1B Visas have infiltrated the US workforce and write substandard non optimized code.
I hope one day there's a virus that will wipe these bastards off the face of the earth.
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
Getting a hold or writing the design document FIRST. Probably less of a problem for programmers on larger projects but when doing in house business apps its so easily overlooked as a waste of time. My most successful project all had a design document written up before I ever even opened the IDE. Other projects that were kludges did not have any kinda plan and grew organically into a mess (they worked but could have been more efficient, cleaner and done faster)
Right now we have one project that is struggling (not my responsibility fortunately, they went outside for it) and when I'm brought into the conversation I keep asking them if they got a design document for the project yet. I think a bit of scope creep is starting to hit them as well.
1) Building a career is mostly about building relationships instead of coding. You have to know how to code well, but it is not enough to build a solid career.
2) Invest some of your precious learning time on skills that do not become outdated with time: OS shell scripting, regular expressions, SQL, etc.
3) Take great care of your health. It's more important than any project.
Learn how to use version control like SVN or Git. They usually don't teach that in the classes you take, and you'll absolutely need it in the workplace. Also, learn how to read, understand, and modify code in large projects.
Slashdot.
Casteism
everything starts and ends with requirements.
if the reuirements are defined in terms of functional tests, its very difficult to have accidental bugs. almost all bugs end up being due conflicting requirements, which simply need to be resolved.
with this method, we can replace junk food and cafine with planning
When the owners of a startup offer you a low paying job in return for an equity position, get it in writing.
Get an employment agreement in which you cannot be transferred without your permission, or canned without cause.
Have it say that when you are terminated, you may exercise any stock options and have a golden parachute for 5 years at your highest salary.
Understand the "Call Girl Principle."
that doing QA (manual or automated) testing is far easier. And a great QA person is harder to find.
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").
Most of the time when i get into a new project i have to take care of code which i did not write, which is not documented and nobody knows the reason why the code is the way it is. And then you have to do a lot of bugfixing in this code which is sometimes the worst code you have ever seen.
A rewrite is too time consuming but making the code better is too. Management most of the time decides "just fix the bugs" but you often see piles of shit of code and the only thing is to understand that weird code and fix it. That is somehow annoying but thats the way it is.
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.
Be a craftsman. Always work at being better at your craft. Sharpen your tools. Understand not only what works, but WHY it works. Never stop learning.
Yes, SDC was a special place with lots of sharp people back in the day. I worked there as a vendor from '77 to '81. Maybe the most intellectually challenging organization I have ever been.