What should an amateur programmer know about professional programming?Possible Duplicate:
What should every programmer know? [1]
I think many amateur programmers are here who are just writing programs, games, websites, demos for fun in their free time.
I think many of them dreaming about getting a programming job in a company and earning a lot of money.
I'm an amateur programmer, who code games for fun for more than 6 years. I'm now at a college and learning programming and I start to realize that programming in large is not as fun as writing a game/demo at home. It seems I should think again everything from the start.
I don't have working experience yet, but I expect to be in the "battlefield" in 1 or 2 years after I graduated.
What should amateur programmers expect when they start working or want to work for a company?
If you want to make a career out of this you have to enjoy it. You have to want to continuously learn and improve yourself.
It's not all fun and games. There will be things you have to do that you don't want to do, find boring, find stupid, and give you migraines. It comes with the turf.
Don't be scared to
You will never reach a point where you know everything. I know people who have been programming for the past twenty years and still are finding new and exciting things to learn or use. The world is practically exploding with new things coming at a constant stream that you cannot possibly get caught up to it all. Don't worry about getting bored, you won't.
I've been a professional software engineer for more than two decades now. Here are some important things it took a while to figure out:
Your fellow developers are not your competitors - they are your brothers and sisters. We are all in this together. This means part of your job, whether your bosses agree or not, is to help teach your brothers and sisters. This means that you have a moral obligation to not leave your brothers and sisters an indecipherable mess to clean up when you move on to other assignments.
Yes, we earn more than burger flippers. Even so, it can't be just about the money. Software development has to be a labor of love. Your bosses will forever look upon you as an auto mechanic with delusions of grandeur. A similarly intelligent person can put a similar amount of effort into learning to be a good lawyer or doctor, and will end up with more money and far more respect. If you want money and respect, do one of those. Only be a software developer if you can't stop yourself.
You spend a lot of time maintaining old code and not a whole lot of time designing new code.
First professional developers have to think in terms other than what they personally want to do. That means you use the tools that your boss tells you to use even if tool X is so much cooler. That means that you program the user interface the way the users want rather than use that neat new functionality you just learned. That means you think in terms of the poor soul who will have to look at this code in six months to maintain it. It means using source control, always. It means being able to follow directions and dealing with pressure to meet deadlines which are often unrealistic.
It means being able to understand the code other people wrote and not refactoring it just because you think you know a cooler way to do things (there are probably business reasons why some past decisions were made and you shouldn't change things willy nilly in the real world). Note - I am not against refactoring when it is needed, but refactoring code you weren't asked to fix when you aren't getting the work you were hired to to do done is deadly. Forgetting that refactoring may introduce new bugs is also deadly, refactor when the process is broken or poorly performing not when you think it might be fun or because you personally don't like Joe's coding style. Users hate it when you change something and it breaks something else that has always worked before. They get really cranky when you did it without being asked to and for no reason other than your own personal preference.
Professional developers learn to work in teams which means listening to other people's input, it may mean (and should mean) code reviews which are a great learning experience but which can be hard on the ego. It may mean - gasp - meetings. It means participating in discussion as to how to do things, but doing the work the way that was decided even if that wasn't the way you wanted to do it. Other people are depending on you doing your part in the agreed on manner.
It also means that the more junior you are the less interesting work you will be assigned. Why should I give the most interesting stuff to you in preference to Sally who has worked here for 5 years and knows the system inside out and who is better qualified all around for a hard task and who I know will not let me down? You get to be a person who gets the most interesting tasks by being a person who reliably delivers even when the task is boring.
You won't always get to code on exciting games/demo/website's.
Sometimes it's just a boring business app that hopefully will get used. You have to do just a good a job on those apps as you would something interesting.
If you actually enjoy coding, it won't be a problem.
Either program because you love it or pick jobs based on money, it is unlikely you will get both met.
If you like to program, and your life doesn't require much money, you may want to look at trying to write some software that is sold. or open-sourced, so you can start to get experience dealing with users, and if you go open-source, you will see what it takes to write something that interests other developers.
Startups are a good opportunity to get some experience writing new code, and if you have been programming for 6 years you are not exactly a newbie at development, I expect.
Many instructors, in my experience, don't have current real-world experience, so you may want to read blogs from developers to see what life is like outside of school.
Get good at learning new ideas quickly, so don't think that one language or framework is the perfect choice for all cases, but learn to be very flexible, as things are changing faster than before, so adaptability is key.
If you love programming games and have been making them for years, why not become a game programmer? The pay isn't as good as other programming fields and the hours are usually (but not always) worse, but you get to make games for a living which is an awesome thing.
I have been a professional PHP developer for almost four years now.
One thing to really remember is you will never, ever stop learning. Every day you will pick up something new, but that is just part of what makes it enjoyable. Even if it is messing around with HTML5 and CSS3, or just some functions in PHP you've never had to use before.
In your working environment you obviously cannot be as cavalier as you are in your home one. One thing many programmers fail to realise is a business case to do something is very important. It might be well and good fixing that ten year old code that just looks horrible, but unless there is a real reason to, normally it's broken is one that works. And not just 'broken'. I mean, actually broken.
Don't be too quick to pick up on the 'next biggest thing'. There are plenty of narcissitic know it alls in programming who are quick to point out how amazing they are because they are using Virtualisation/Memcached/etc. Technologies, certainly have their place. At the same time, think about the scope of your projects. A common fault of many a programmer is overengineering a solution.
Don't be arrogant, but be confident but modest. Judge everyone on merit, not just years of experience or education. One of the best programmers I know has no degree, or I believe A-Levels. A willingless to learn, and flexibility will help out massively. I've seen plenty of people describe themselves as seniors, or even middleweights who couldn't tell you the difference between require and include in PHP, or knew anything about SQL injection. I would say I was a middleweight today, but never was ashamed to be a junior.
Another really useful trait to have is the ability to talk to people. At at previous company a developer would actually send back stack traces to a manager to explain why something wasn't working, but being able to describe things in simple terms is golden. It's actually useful to be able to jump between a few levels of technobabble actually. Of course, sometimes you might need to explain simply how something works.
If you can, have a home project to work on areas you would like to learn. You don't have to do it all the time, but it can help keep some enjoyment when you are going through more boring patches.
On a PHP front, and I am sure I will be lambasted by some for saying this, but avoid too many Frameworks whilst learning. You tend to learn 'their' way of coding, and their classes and you tend to lose a bit of experience in doing things for yourself, and if you aren't careful you do get a bit lazy, as is evident by some of the other code I have seen recently.
Do not ever be afraid to ask questions.
The biggest difference between amateur and professional? The people. In most businesses you'll find that you have to work with people towards a common goal. You won't be writing entire projects by yourself and you're not going to have control over nearly as much.
You're going to have to adapt quickly to things that aren't necessarily "right".
That there's really no such thing as a professional programmer.
The people doing Software Development as a Career are really just people that enjoy solving problems with computers...whether it's hacking together a new game, architecting a new Enterprise Application, or digging through code trying to debug the last guys code.
Professional programmers can have a wide variety of jobs. What you should know is what each of these jobs is like so that you can choose a job carefully. First off, professional programming is like any other job. You can do something you enjoy doing, but the job can take the fun out of it if you're not careful. Instead of writing a game and adding the features you think are cool and taking the time that is needed to get it done, now you have to write the game that someone else wants, and you have to CONVINCE people that your cool features should be in there. You also have deadlines that may or may not be realistic and which you probably didn't choose.
I've done it for a long time, so here are my subjective observations.
New code is more fun than fixing old code.
New code has deadlines, which can be stressful. Old code fixes can sometimes be "downtime emergencies" which are SUPER stressful.
New code requires engineering and design. Old code can always be fixed without you having to do a good job (you can always blame the existing code for being slightly unfixable).
Contracting can be both new code or old code.
Contracts working on new code tend to be shorter than contracts for maintaining old code.
You will usually be blamed for mistakes you make in new code. You are not as likely to be blamed for mistakes you make in existing code, unless management or a nasty coworker digs in to prove where the mistake was, and even then the blame is negotiable.
You may find that you foster new interests in parts of programming where you once had no interest. I thought I'd never adopt managed code development but now I find that it presents motivating challenges that I enjoy.
Programming paradigms change every few years. You must keep up if you want to have marketability.
To keep up, it helps a LOT if you LIKE programming.
To have marketability means that you can quit if your job sucks. Programming is programming (mostly) but there are good programming jobs and bad programming jobs. Along the same lines, you realize that you still have to work with people in a programming job, and some people suck.
As a contractor, you usually work where there is money. Contracts always end. As a result, you should make much more money and have few or no benefits as a contractor than as a full time employee.
Long-term full-time employment may span many up and down cycles in a company's financial status. In the down cycles your employment can still end. You should make less and have better benefits as a full time employee.
If you have a project manager, his job is to make decisions. You must communicate with the PM. They will be responsible for those decisions. If you don't communicate, they can blame you for their bad decisions.
Some projects fail. That means that they don't launch or they launch but don't make money, etc. Sometimes the programmers are at fault, but if the programmers communicate, the fault is usually management. If you are considering a contract, consider this. Avoid pre-doomed projects. Get all the information you can when considering the job. You will still work on an occasional failing project. There is usually nothing a programmer can do to make a doomed project work.
When working at a full time employment position for many years, you find that the place where you're working has a certain way of doing things. You eventually find them to be routine and you get very good at them. But this routine keeps you in a little bubble where you're not exposing yourself to a variety of technologies and challenges. It may be a good idea to jump contracts for a while to round out your experience and stay marketable. If you stay at a job for 15 years and then the company goes out of business, you have been isolated from the changing world for too long and may have to go back to school or otherwise retool.
Point #1: Somewhat duplicating what HLGEM says:
The biggest difference between hobby projects I do at home and projects I do at work is that on a hobby project I do what I want the way I want to do it. At work I have to do what the user wants and I have to do it the way the boss wants it done, to one extent or another.
Professional programmers spend a significant percentage of their time figuring out what the user really wants. Often this is not the way you think it ought to be done. One of the biggest lessons some developers have to learn is that it doesn't matter how you think it should look and feel and work, what matters is how the customer thinks it should look and feel and work. When you go to a fine restaurant, you expect the chef to prepare the food the way YOU like it, not the way the chef likes it. Any chef who takes the attitude, "I don't understand why people like their steaks well done, they're obviously much better rare, so that's how I'm going to cook them no matter what the customer says" isn't going to last long in the restaurant business. The same thing applies to developers who try to overrule users on software specs.
Point #2: Real-world projects are often far less cool than hobby projects. I spend most of my time on mundane things like modifying the interface between two systems to change the format of a certain field, or adding a new report that looks a lot like an existing report but includes an additional column and sorts differently. Maybe if you work for a video game or robotics company you get to work on way-cool projects all the time. Actually I suspect that most of their time is spent on mundane detail changes, too.
Point #3: On professional projects, you spend a lot more time on data entry and error-checking than you do on hobby projects. At least, when I do a hobby project, usually that means I'm the only person who will ever run this program, so if a data entry error means that it crashes with a cryptic message, so what? I'll know what it means. But for a professoinal project, you have to check for every error imaginable and give the user a comprehensible message. You have to check for utterly stupid errors, like leaving an obviously required field blank or entering your name into the balance due field.
I'm sure there are lots of people who think that something is way fun when they do it for a hobby, but once you try to do it professionally it becomes a lot more like work. I guess it's all a question of just how much you love it.
I write code for web applications as my day job. In my evenings I write a lot of fun and experimental code.
A lot of posts here suggest you will hate your job as a coder. That is up to you and the situation you find yourself in. I'd like to suggest that even if you don't like your day job, it doesn't mean you can't do what you love in your off-hours.
(Yes, burnout happens from time to time, but that's generally nothing a weekend off in the woods can't fix.)
Professional programmers are just people who are paid to solve problems where, generally speaking, the solution can be effected with software. As a professional programmer, you will have the most fun if you can learn how to make your clients' problems your own. When you harmonize your desires with those of your clients, you will have fun developing creative solutions to their problems because you will already have a desire for the solutions as well. Your clients will love you because they can relate to you via your shared interest in these solutions.
You won't be programming as much as you want to. When I was in college I thought working for a fortune 500 meant 12 hours of coding, all day long and it would just be a big ball of fun. What you get is periods of maintenance coding, no coding, and, if you're lucky, a long 1 or 2 year project. As a .NET programmer, I've had to do ABAP (SAP) coding because there was no other work. But that's not the worst part because it's still coding. The worst is when you have to help the analysts run automated tests for SAP and you have no idea what you're doing but you're expected to get this testing done in 8 days. And then the 8 days starts dwindling down as meetings about the status of the testing takes more of your time and you end up wishing you could move to another team so you can do more coding. Sorry, I got carried away for a minute. Anyway, you won't be doing what you love to do all the time. And that's what sucks!
I to am a college student and CS in my major and yes the classroom is much different then what work will be like. I found a great Internship at Auctiva this has been very helpful as well as this article.
http://www.joelonsoftware.com/articles/CollegeAdvice.html
keep coding and looking! good programmers get good jobs!
M
Word professional is "to make money from skill," but real professionals also have a set of qualities, which are:
when i say dependable, it means according to software engineering standards. Dependability needs
For professional Programmer. Programming is not only fun but more of responsibility. Professional must do complete justice with his/her profession.
What should amateur programmers expect when they start working or want to work for a company?
Programming for a company won't be nearly as much fun as it was when you were an amateur. Oh, well.
One thing that you need to know about programming professionally is that as with any profession, you're obligated to do stuff that isn't fun, but is part of the job.
You'll have to bang your head against the wall for days on bugs for 5% of your users who are still using Windows 95 (ok, maybe that's an exaggeration, but you see what I mean).
You'll work with other people that you may or may not like, and who may be better than you, as good as you, or worse than you, or who may simply have a different style.
When you're writing code on your own you don't get calls late at night because someone you gave your code to needs you to fix an issue immediately. Well, maybe you do, but you can ignore them.
You won't always get to work on what you want to work on. You may have to work on things you used to enjoy, but after years of fixing the same kind of bugs you're sick of it. But hopefully you can enjoy architecting and implementing the things you do get to work on.
The best advice I can give is be realistic. Do you enjoy it enough to take the good with the bad? It's like any other career. Enjoying playing guitar doesn't mean you're interested in a career in the music industry. It's the same with this, only you get more women writing software than you ever would as a rock star! ;-)
For a starter in programming, I think Professional Programming is to solve mass questions neatly by using math and algorithms, and get some Pro.s working together as a team like mentioned above.
I am not a pro and I want to be. SO is good place to study and becoming into a professional.
Some Pointers:
A program is worth nothing, but the use of it will produce value for the user. One must do everything to protect that value gain. That's where reliability, ease of use, performance comes in. The more value at stake, the more your salary could potentially be.
" design patterns [1]" will help break down programs into fundamental concepts. This is important for communicating with a larger team of programmers and managers.
Learn how to talk to users. They might think it's all magic and usually don't understand how anything works internally.
Have the ability to write a library instead of implementing all code at the site of consumption.
Conversely, have the skills to finish features fast at the cost of elegant coding. Both situations will arise in the professional world.
Enjoy the team, and the process, the product itself might not be always interesting.
That the fact that I'm answering Your question does not imply that I'm a professional programmer.
