15 Things Schools Won’t Teach You About Programming
Don’t get me wrong, going to school to learn how to program is great but there are some things that schools seem to miss the mark on and these drive me nuts.
- Copying – well yes, cheating is bad and you should do your own work in school but it’s also not reasonable to expect someone to go it alone on a project in a job setting. Your manager won’t ask you to live in a bubble of seclusion when they want you to complete a difficult task in a short amount of time. In fact they’ll encourage you to use outside resources and other programmers to get the job done. This is one of my worst pet-peeves about schools. Sure you need to know how to program but in the real world you aren’t required to go it alone without any kind of external resources at your disposal or the collaborative programming with other co-workers.
- Scope Creep – so in school your projects have a nicely defined list of features and requirements your professor wants you to implement. However the real world isn’t so nice and cut and paste — even if you have well developed requirements. The fact of the matter is you often won’t know what requirements you need to fulfill until you stub out some kind of prototype and show it to your clients and get their feedback. In addition you’ll typically find things that you didn’t think about which make you scratch your head and go back to the drawing board a time or two.
- Text Book Solutions – if you’ve ever done an assignment from a textbook with an answer key in the back you know exactly what I’m talking about. There’s always that one solution that’s deemed the “correct” answer. In reality there often isn’t a single solution to a problem and what may work as a solution in one environment is a complete and utter failure in another as the scale or complexity or speed of the results actually hinder the user experience.
- Making The Grade – everyone knows you’re supposed to get straight A’s in order to get a good job after school. Wrong! I’ve never known an employer to ask for a GPA or how many times I failed a class. The truth is your grades don’t matter, it’s your knowledge and experience that count. So what if you have straight A’s in every class you ever took if you’ve never had any practical experience building your own program or working on a large, complex project. No one cares what your grades are, they want to know you can get the work done well and in a timely fashion with minimal bugs.
- Re-Inventing The Wheel – yes it’s important that you understand how and why something works but schools are notorious for having their students re-invent the wheel. Let’s write five different types of searches that most languages have built in functionality for, or let’s write a function that swaps two values so you can use it in later projects. Please, don’t re-invent the wheel. If it’s already done for you then why are you wasting your time? Understand how it works and then take that knowledge and build something useful, don’t just regurgitate what’s already been done over and over again.
- Debugging – this is one of the most useful skills you can have and yet schools are sadly lacking in teaching students how to intelligently debug errors and use helpful debugging tools. In addition most schools stress actual programming when even the software life-cycle emphasizes maintenance and bug fixing as a majority of the time spent on piece of software. Why are schools leaving this out of their curriculum when most new programmers are tasked with bug fixes in order to learn how a large piece of software works?
- Documentation – there is a sad lack of acknowledgement for documentation in programming. Some schools will skim over it briefly but for the most part it’s a passing reference in a class. I’m amazed at how many new programmers I interact with who have thousands and thousands of lines of code without a single comment. Now some of you may argue that documentation isn’t needed however if you’ve ever returned to work on a project you set down years ago you know those hours you spent trying to figure out why you did something that you didn’t document could have been better spent with the 5 minutes documenting it in the first place.
- Deadlines – in school you’re given long deadlines to get something done. Deadlines aren’t as set and fixed in a job setting. One day your boss may walk up to you and say “I need this in an hour.” If you’re always used to long, drawn out deadlines then you get that deer in the headlights look in your eyes. Of course this works both ways, and I’ve worked on projects that have no deadlines either. The point to take away from this is deadlines are flexible and rigid, achievable and impossible to meet and not a fixed point in time and space.
- Multitasking – in school you only work on a single project at a time until that project is done. A job setting is far from that. You may start a project one day, have it scrapped the next day and then returned to you six months later. In addition it’s common to be working on multiple projects at a time as you wait for other requirements or client feedback to trickle in. Asking students to work on one project at a time is detrimental to them learning how to multitask and adjust as the situation warrants.
- Pass or Fail – schools have a pretty black and white approach to how a program is supposed to work in order for you to get a passing grade. What they forget is often times a project just needs to be “good enough” due to deadlines or budgets or resource constraints. Something that is good enough to meet the requirements doesn’t mean you failed, it means you have room for improvement and re-factoring.
- Refactoring – I would love to see a school tell a student to take the first project they completed at the beginning of the year and re-write it with what they know now. Re-factoring is a major aspect of a programmer’s job and yet few students are asked to look at their past work, reflect on how it could be improved, and then set to the task of improving it. This is something most programmers are faced with on a yearly basis as they complete new iterations and features of their software.
- Coding Together – since schools are so intent on grading you as an individual the students miss out on the ability to code collaboratively. There is rarely a time when a complete piece of large software will have been written by a single person. Being able to read and understand other people’s programming and to match your style to theirs is a huge asset and ability that shouldn’t be overlooked.
- Best Coding Practices – so you learn the programming fundamentals but you’re hardly taught when you should use one rather than the other and where, how or why you make that decision.
- Code Style Guidelines – one of the biggest indications of a good programmer is their coding style. Code that is easy to read, indented properly, and consistently written is essential for improving maintainability of a piece of software. Most new programmers run their lines of code in big long strings with inconsistent spacing and style guidelines. Would you rather read 1,200 lines of code condensed onto 5 lines that makes you scroll infinitely in your editor to read them or properly indented and spaced code in a logical and easy to read manner? I know which one I’d choose.
- Experience – there is no substitute for real experience. No school can give you anything more than an introduction to programming no matter if you spend a year or four years learning and expanding your knowledge. There’s a wonderful article by Peter Norivg that I like to give anyone whose interested in making programming a profession. You can’t take ten years of experience and condense it into a quick fix or four year series of courses. Experience will always be your best teacher.
