Three Things I Learned About Software WHILE NOT in College
Dare Obasanjo has a great post on the "Three Things I Learned About Software in College," while Jeff has a fine post called Learning, or, Learning How to Learn that points to a great post called Why Is Forever. Jeff says "How lasts five years, but Why is forever." This is a great lesson to be reminded of and a pithy, but true, statement.
Here's Dare's three things learned in College. Be sure to check the comments on his post, there's some great stuff in them.:
- Operating systems aren't elegant. They are a glorious heap of performance hacks piled one upon the other.
- Software engineering is the art of amassing collected anecdotes and calling them Best Practices when in truth they have more in common with fads than anything else.
- Pizza is better than Chinese food for late night coding sessions.
[Dare Obasanjo]
I learned some stuff in College, but here's the "Three Things I Learned About Software WHILE NOT in College" as well
Things I Learned about Software in College
- Everything has already been done before and will continue to be re-written over and over until the whole world embraces Lisp.
- TCP/IP is a beautiful soup.
- Beauty is skin deep, but ugly goes through to the bone. This statement often applies to software. Don't go digging if you don't want to find a hack.
Things I Learned about Software While Not in College
- The more complex the software being created, the less the problem becomes about technology and the more it becomes about interpersonal communication and group dynamics.
- You're not going to need it (YAGNI). You'll always want to add one more method to a utility class, or speculate on how your software will be used, but ultimately you need to keep code and features as constrained as possible.
- Every line of code you write that you feel gross about will ultimately come back to haunt you. Therefore, avoid writing code that makes you feel dirty.
...and I'd ask you, Dear Reader, to share your three things, learned both IN and OUT of college. I'm especially interesting in those who didn't go to college at all, to add yours.
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
http://www.kenegozi.com/Blog/2007/06/28/things-i-learned-about-software.aspx
1. No matter how good you are in college, you are going to be modifying someone else's code during your first job (either while in college or fresh out of college.
2. There is always going to be someone with a fresh idea that you have not considered for your solution.
3. There is more than one way to solve any problem. The professor's way, the wrong way, and your way.
Post-College
1. See #2 from in college. You are going to meet and work with some brilliant people during your career. I am humbled by the bright minds I have had the pleasure to work with during my career.
2. There is always going to be a better mousetrap that can be built, but do you have the time, money and backing to build it?
3. No matter how good you are, you can't solve every customer's problems; they quite often want something that they don't necessarily need or have any idea what they are truly asking.
1) Coding is all about maintenance. -- Code is never written and that's it somebody has to keep it working.
2) It's all about strings and ints. -- Really, isn't 90% of all programs just messing around with strings and ints?
3) Most programmers will be working on the equilivent of a mainframe application in 15 years. -- Isn't the web just a glorified 3270 session anyway?
So, what I learned in college was that if you want to make it you better do more than just count on your college education :)
What I learned outside of college...
1. Waiting until midnight to start a program that is due the next morning at 8AM isn't the smartest thing to do.
2. Testing is the difference between a program you think works and one you know works.
3. Backing up your source code is mighty important, particularly when it is 3AM. (See #1)
After College
1. Dealing with the human stuff is much harder than dealing with software stuff.
2. Finding a place where smart people who love their jobs work is far more important than dickering over salary. Money is good, but job satisfaction is better and the money will come.
3. The best part of software development is the problem solving.
Do you like the full justification that dasBlog uses when there are only a few words in a line? The line looks weird and it slows the reading. (See Dare's comment above)
Also when a sig is hyperlinked, the sig including the white space on the line is hyperlinked.
.. 95% of what I learned about software was self taught out of college.
Persistence and patience pays in software
1.
Wait. This live preview thing is the cat's whiskers. Look, It's typing right along with me! How does it know what I'm going to type next?!
[ahem]
1. Software is lots of maths.
2. You're a complete imbecile and unworthy until you've mastered the STL and can use it without reference materials.
3. Two's complement is 1 + One's complement.
After college:
1. Not so much maths. Maybe just a little.
2. What's the STL? We can't use it here because the header files conflict with MFC.
3. It takes just as long to decipher code and make the update as it would have to write the documentation 6 months ago.
Where's the 'source' button. I don't like how this live comment thingie is making me sound.
http://blog.butel.co.nz/2007/06/29/three-things-i-learned-about-software-while-not-in-college/
In College:
1.) Branching Logic
2.) Looping Logic
3.) Some people just don't get it
Not in college:
1.) College doesn't weed out the people that don't get it.
2.) You never stop learning
3.) Everything else
http://gatesvp.blogspot.com/2007/06/3-things-i-learnt.html
In University
1. It's all just another layer of abstraction
2. You can't learn without doing, but you can't do without learning, so try both at the same time.<
3. "Why" is always the question, "How" will be left as an exercise to the reader
After College
1. It's all just layers of abstraction, so the most important thing is always that which you are abstracting.
2. Clients don't know what they want, 'cause it's generally not their job to know. That's why they're hiring you, you and the software are the next layer of abstraction.
3. Always keep a paper handy (or maybe OneNote). The task of programming is simply too vast to be completely consumed at once. You will always have more than one item at work and more than one monitor's worth of material, so live with it :)
1. No one except me knows or cares about the definition of "Liskov Substitutability Principle"
2. Great computer scientists are sometimes horrible programmers, and it doesn't matter!
3. Just because the syllabus says "70% is an A" doesn't mean the class will be easy.
Afterward
1. One of the most important software development skills is how to spend more time programming and less time waiting for other people.
2. Software development is deeply segregated. Everyone confuses their niche and culture for the whole thing.
3. Complex software can be written by a bunch of sub-par developers with a lot of patience.
And since I got inspired to make my own post with the exact same title, here is the link of anyone is interested: Three Things I learned About Software WHILE NOT in College
Cheers.
1. 1+1=0. Two students can get the productivity of zero students if the communication/organization isn't right or one of the students isn't up to the task at hand.
2. Adding man-hours to a project seldom solves if. Getting smarter or more informed solves it.
3. Hacks are bad
Afterwards
1. 1+1=3. Two developers can get the productivity of three if the organization is right.
2. Man-hours is what ultimately solves a problem. You can't just think about the problem all day.
3. Hacks are vital.
- You become an expert in the syntax of languages that no one really uses.
- You are taught how to use the STL, not how it works...you believe it has no design flaws.
- You use cleverly built labs from grad students, never learning infrastructure skills like makefile writing.
After college:
- You understand how to use a debugger to set breakpoints, print traces, and watch variables.
- You use revision control, bug tracking, and test frameworks religiously.
- You realize that half a page of clear code is worth much more than a clever but unreadable one-liner.
After working for a few years
- Delivering matters. A lot. Have a deadline, stick to it (cutting scope if necessary).
- For better or worse, most people won't care how elegant your implementation is. (But you'll have to live with it. For a long time.)
- Keep lines of communication open. Even if it is bad news. People know and appreciate when you have to balls to be straight with them.
1. Fortran 77 sucks (I did Physics not CS)
2. This internet thing might just catch on now that you can have a background other than grey
3. Telling people you are the manager of the local bar is a lot more likely to win you friends than telling people what your major is (see point 1 above)
Out of college:-
1. There is no smoke and mirrors. Compuer science is derrived entirely in the minds of man, therefore even the most complex and scary looking system / architecture / idea should be understandable if you think about it long enough. Usually, when you have it figured out, it wasn't as complicated as it looked.
2. A suprising number of people working in IT don't get "it". When you find ones that do - try and get them on your team and you'll usually have a lot more success but you will definately have a lot more fun.
3. It is hard to make a computer interface transparent and takes more code than you would think - even today. Worse still if you manage it, demonstrating it is even harder - people just assume that is "how things work" and quickly forget what it used to be like.
2. Know Excel/VBA and you'll probably never go hungry.
3. If you take on board one concept from Agile, take YAGNI. If you have room for another, DRY.
* Put me down as a University dropout, in case you hadn't guessed. ;)
1. Girls in CS programs are usually flakes. They'd be better suited with an English Degree
2. Grading curves are bad for your degree prestige. When some idiot that should have flunked out is toting the same
degree as you and applying the same places etc. it pulls your credibility down.
3. CS people always think they're right. (for proof, see any Slashdot discussion)
Out of College :
1. You have to leave to get a real raise
2. Recruiters are smarmier than circus folk
3. After 8+ hours of (work)coding, when you get home you don't feel like touching your hobby project
Seriously, though, I second all the comments above that college doesn't filter out all those who don't "get it." Unfortunately, job performance while developing software is very hard to articulate if you're not speaking with someone who isn't a programmer also. It is really hard to describe to a non-programmer that so and so just doesn't "get programming."
Keep learning when you get out of school!
Writing programs using programming languages and logic.
Out of college:
Writing applications is not only about programming languages and logic.
1. Those who can, do, those who can't teach,
2. Every application or language you use has been chosen for an emotional not a business\educational reason,
3. Sandals & beards are not cool and never will be.
Out of College:
1. Those who can, do, those who can't teach,
2. If you want to be an idealist go back to college,
3. Software generally does not interest people outside of IT\engineering.
1) A lot of people getting a CS degree will never be able to write a real program (as I was getting my degree in structural engineering (CE)).
2) How new features and scope creep can cause projects to be never ending, and end up not being released at all.
3) You don't have to have your future life/carrer planned out, but it helps.
Learned OUT of college:
1) Just because someone has "Sr." in their title doesn't MEAN they know anything, but they might. If their logic sounds flawed, don't assume it is because they are "Sr" and you are "Entry": you are probably right.
2) "Expert" can mean different things to different people. You can be in the top 2% of one company, but a middle of the pack guy in another. Avoid calling yourself an "expert" (or acting like one) unless you know who you are talking to, and you actually are the expert.
3) There is no "Best" way to do most things. I had thought that if I looked hard enough and studied enough examples, I would know the "best" way to do things when I arrived at them. But one groups "best practice" is something another group will not touch. See the current OR/M arguments for a perfect example, or if you prefer just look at divide over using Datasets.
That being said, there are definitely some agreed upon "Worst Practices", so avoid these at all costs.
1. The bar for "good enough" is depressingly low in the corporate world.
2. My ego is my enemy
3. Maintenance is a huge time suck.
2) Some women want to have sex as much as you do, they just keep their cards closer to their chest.
3) The more clear the liquor is, the less of a hangover I'll have in the morning. And don't mix beer with liquor.
1. The elegant solution wins.
2. There are many people much smarter than I am.
3. The university staff will actually help you succeed.
After:
1. Code that works wins.
2. Find the smart people and work with them.
3. Management is out to get you.
1. Users don't know what they want, they only know what they don't want.
2. Play nice with your colleges.
3. You can't do it all yourself - learn to delegate to competent people.
4. Never underestimate the stupidity of the end-user.
1. It has often been designed and developed extremely badly.
2. The better a person's level of degree, the worse they seem to designing and developing software.
3. Developing software is much more fun than system administration.
1) Pointers are awesome, and any language that doesn't have them isn't worth using, and accordingly, C++ is the One True Language and other languages are slow and/or crappy to work in.
2) How to write a hash collection class, and to create and use a Singleton class (in place of global variables).
3) The waterfall process is the only way to really get things done right without chaos consuming your team.
Things I learned not in college:
1) Pointers are an absolute pain in the butt unless you really need them. C++ is still important, but in the shadow of things like .NET, Ruby, and Javascript (none of which have pointers!!) I can now see it for the "old man" it really is.
2) When not to use a Singleton class. And if your language of choice has a built in hash class, use it. Never write your own unless the need is dire.
3) My "software engineering design" teacher from college seemed totally unenthused to be teaching us the waterfall process for a reason: because it sucks for software development in the modern business environment.
1. Boolean logic can help prove a statement.
2. Comments should be added to code for clarity.
3. Projects should be completed on your own.
Out of College:
1. A test, or set of tests, is much clearer at proving that code is correct.
2. Good code needs well-named, decoupled, highly cohesive parts, NOT comments.
3. Asking for help does not mean that you are weak, it means you have the strength to admit that you cannot accomplish something on your own.
1. Strangely, all of this really low-level crap i'm doing in school isn't at all what I need to learn in the field.
2. I sadly learned that I could wait until the 11th hour and still succeed in school.
3. Learning a new programming language takes six months to do.
What I learned in the field
1. Learning a new programming can take a week if really submerged into it. (Swim with the sharks)
2. I can NOT wait until the 11th hour to start an application. Something unexpected will *always* happen, plan for it.
3. Writing software isn't hard. Learning about how software works in the corporate/business world works is hard. (read interpersonal communication, politics, egos) above.
1.) Knowing how to code better, and knowing best practices, and knowing methodologies that encourage project success doesn't necessarily mean that I'll have the discipline, resources or support to use that knowledge.
2.) Just about the time you think you know what's wrong with the system, chances are, you don't.
3.) When it comes down to it, and it's a question of job satisfaction or money, choose job satisfaction. Contrary to popular belief, money cannot make up for a miserable work environment and the stress that goes with it. Even if they offer you more money to stay, find a better environment if you're unhappy where you are. To put it succinctly: More money != happiness. Happiness == happiness.
http://webgambit.com/archive/2007/06/28/things-i-learned-about-software-in-college.aspx
Things I Learned about Software in College:
1. If getting things working is the primary goal, most programming assignments can be completed by one person in a reasonable amount of time.
2. Reaching the "ah ha!" moment in programming is very important. Until you reach that moment, every programming assignment will be marginally tougher.
3. Don't work on assignments with the smartest person in the room. Immediate learning by imitation doesn't work too well in software. Find your own way that works first, and then improve your style by emulating others.
Things I learned about Software after College:
1. Most good software is built by teams, not individuals. If you don't understand this point, you'll always be a second-rate developer. No matter how well you hack things together.
2. Being a software professional truly means being a lifelong learner. Chances are the tech you cut your teeth on in college will be obsolete soon after graduation.
3. True happiness as a software developer lies in liking those who you work with, not liking those who you work for. Some of my best work experiences were great because of the amazing colleagues I had a chance to work with, not the company or brands I worked for.
Three things I have learned about software and college
1. ) If that Variable, Procedure, Function can't tell you what it Is/Does now, what happens in six months.
2. ) Unless you really know 'Why', You can never get the 'What' right or know 'How to'.
3. ) Sourcecode is for people, machinecode is for machines. (Trust in the source Luke, only in the source')
3a) If that short bit crypto hash onle liner actually compiles better than a simple step by step procedure then you need to get a real compiler. See 3.)
4. ) If you aren't doint an interface, OOP is just shorthand for OOPS. See 3.)
5. ) The hardware specs always leave someting* out. er(* something, atleast as of Ver 1b)
6. ) If it's so simple a monkey could do but they just don't have the time, RUN!!!!!
7. ) Never take on a tiny peice of a big project if you aren't involved in the whole thing. See 2.)
8. ) Language skills are universal, if they can't explain the project, the library, the point, Etc in complete sentences, the inhouseware is just as bad.
9. ) Hardware vendors don't mean to lie.
10.) Software vendors mean to mislead. (It's in the next revision, Honest, what was the problem again?)
11.) If the inhouse libraries cover everything you could ever need, either climb in the box and make a nest or climb out and RUN!!!
in College:
1) ask the professor: why aren't you teaching us more about writing software? A: because we're teaching you to be computer *scientists*, you can learn how to program in a tech school.
2) javascript and perl aren't real languages.
3) C was fun, C++ is a turd. But your professors will still grade you on how well-polished your turd is.
Real Life (as a contracting software developer):
1) It's startling to discover just how "average" the average programmer is. It's startling to see just how bad is the legacy code written by the average programmer, and even more startling to see much the company relies on it. But there's always some "local genius" who somehow makes it all work.
2) Keep in mind the murphism: If architects built buildings the way programmers write code the first woodpecker to come along would destroy civilization.
3) Javascript and Perl are the duct tape of web development. That makes them real languages.
4) C++ is still a turd.
5) If you spend too much time congratulating yourself for being smarter than the bunch of idiots you're working with then you're really only the smartest idiot, aren't you? Remember, these people aren't idiots. Only the end-user and management are idiots ;-)
1.) If the master copy is stored in more then one place, one of the places will eventually be different. What are you going to do then?
2.) If you can't look at code you wrote more then 9 months ago and wonder "man, how could I have been so dumb", you're not learning anything.
3.) A good flexible design up front is worth far more than a tight locked down design that gets added to little by little
Of course, I think the last one boils down to the addage "Keep adding a little to a little and eventually you'll end up with a big pile"
... after which it will continue to be re-written over and over, in Lisp.
1. VB programmers aren't viewed as real programmers.
2. Oracle is a nightmare to install - it will take you a lifetime to figure out all the mistakes you can make.
3. There are no female programmers.
Out of College
1. 99.9% of CS graduates don't know the first thing about programming.
2. Software involves sending more emails that writing code.
3. Programming doesn't really involve that much math.
1) You can't be afraid to make a change to source code.
2) Finding a job you have fun doing is almost impossible.
3) Writing a complex system/program is about making simple procedures/functions/objects work together to get the functionality you need. It is not about writing complex procedures/functions/objects.
(1) The real world is on the brink of a core dump.
(2) It doesn't need to be good; it only needs to be better than competitors.
(3) People, not computers, are what software engineering is all about.
* how to build a bong out of an old mouse, some masking tape, and a bic pen.
* most computer science professors don't write code for a living and never have.
* necessary fundamentals that i'm glad i know like data structures, algorithms, compiler theory, relational database theory, and all of those math classes.
after college:
* how to select a nice handblown glass bong at a headshop.
* writing code for a living is a craft that can only be mastered through experience and contact with experienced peers.
* lots of career programmers i've worked with skipped or slept through all of those fundamental classes in college.
- Nobody likes the "question dick" sitting in the front row. If you don't know what that is, it might have been you.
- 1.0E-15% of what you learn in college comes from the books.
- Raman noodles are in the vegetable family.
- Never anthropomorphize inanimate objects. They hate that.
Since College:
- Challenge your assumptions. 99% of every problem you'll troubleshoot will turn out to be because the damn thing wasn't plugged in, not the rocket science explanation you immediately started hunting down.
- You're never done learning. Once you lose the desire, you'll be on your way to the then-current equivalent of COBOL dinosaur status.
- Don't get religious about technology, even when others around you do. Remember, one man's religion is another man's belly laugh.
Outside of college, you learn that the determination of "dirty or clean" software is only valuable with regard to the feelings of it consumer base. All other players are irrelevant.
-----------------------
Paul W
My site
My non profit software
out of college: that simple last minute line of code that couldn't possibly introduce any new bugs will bring down the entire system every time.
1.) coding is primarily a learning activity (practice), and after enough learning, a product development activity (execution). corollary is that only a small percentage of all the code written goes into delivering product. Most of it is thrown away, rewritten, performance-enhanced, bugfixed, in-transition or just experimental. so try not to get too attached to it.
2.) coding is a sport, and a team sport at that. i could go on for hours about this. analogy. but i'll spare everyone.
3.) software is not that much softer than hardware. it is soft for the short period of time when it has never been used and gets much harder as usage increases.
1 - The Programming world is split between those who get recursion and pointers and those who don't.
2 - Kids who get the highest grades are usually the less knowledgeable in the subject
3 - Leaning arcane languages and CS stuff sucks
4 - I suck at math
Out of college:
1 - The software engineering field is split between those who do it because they love it and those who want to earn a paycheck
2 - Your boss probably had high grades in college
3 - Knowing how arcane CS stuff works is what helps you understand the shiny new things better
4 - Math is not as important as it was supposed to be
In college:
1. There are 10 types of people in this world; those who understand binary and those who don't.
2. "I can write better code when I've been up for 3 days straight, sustaining myself on caffeine alone....seriously!"
3. "Wow, there are a lot of really smart people."
After college:
1. There are 3 primary goals to any project: make it inexpensive, make it fast, make it great. Only 2 can every be achieved simultaneously.
2. Love your job...but have a hobby.
3. "Wow, there are a lot of really stupid people."
1) A load of purely academic languages that are never used outside of teaching.
2) How to code complex algorithms that are provided in libraries for languages in use in the real world.
3) Beer is good.
Stuff I learned in the real world:
1) The most vital software engineering tools are paper, coloured pens and lots of cups of tea.
2) Always photograph your whiteboard after a brain-storming session.
3) Requirements are weird because real life is weird.
1 - Coding is fun
2 - Coding is not always fun, if you have no manuals and there is no internet available yet
3 - C++ is not as forgiving as BASIC regarding its syntax, (dozens of errors and an hour of fixing them after manually copying 'hello world' from the C++ tutorial...)
in College:
1 - formalisms without end...
2 - lots of mathematical and theoretical things, you never suppose to use any time soon in your later job
3 - hardware PIC programming
4 - functional programming, though I didn't get the importance it has back then
5 - a glimpse of <a href="http://www.scala-lang.org>scala</a>
after college:
1 - you come across everything you learned in college (but the formalisms ...) in your day-to-day work; if not every day than at least once a year
2 - Java is better than its programmers (perhaps since most of them didn't go to college?)
3 - nevertheless Java suckz, but you will have a hard time finding a work place where you can avoid it/replace it with a better alternative, so fasten your seatbelts and try to get out of it as much as you can
4 - lisp, scheme, ruby, python, regexp
Three things I learned while in college
1. You can spend hours getting a really neato-keen solution working and not finish in time, or you do something the obvious and easy way. Guess which gets the better grade?
2. College professors are full of “back in my day” stories. Many haven’t seen the real world in years.
3. You get a lot more out of things (in this case, college) when you pay for them yourself.
Three things I learned while NOT in college
1. The health and success of the project is more important than your ego. You can argue for your way until you’re blue in the face, then go home and celebrate your victory alone, or concede that other people have good ideas too and celebrate a successful project together.
2. The perfect is the enemy of the good. If you have two options, A and B, and B will take an hour longer to do, and you spend half an hour successfully arguing to do A, you have gained nothing. If you have an algorithm that takes 15 minutes to implement and will save 2 minutes of CPU time over the next five years, you have gained nothing. *
3. 25% of your time should be spent planning what to do for the next 75%. This includes design after design after design until you get it right.
* If I weren’t trying to stick to the limit of three things, I’d add another item here that ties into #2: CPU time is infinitely cheaper than programmer time.
I may have a different perspective since I don't have a degree and never really took any college courses.
1. Don't show your customer what they don't need to know.
2. Visual BASIC and C++ don't mix. Beware the VB programmer that passes all data as strings.
3. A verbal specification isn't worth the paper it's printed on.
http://bge-kernel-panic.blogspot.com/2007/06/3-things-i-learned-about-software-in.html
1. If you are a female programmer, you are a bimbo.
2. ..... or you don't exist.
3. Should I have an existential crisis now or practice different hairstyles in the mirror?
Things I learnt after college
1. The need for balance between perfecting the design and actually starting the damn thing; writing perfect, self-documenting code verging on pure poetry and actually getting the damn thing done... Half the battle is in getting this balance right
2. With features, start small (smaller than your ego wants), release, and THEN build
3. It is often more useful to talk to the end-user about his job in general and if possible, put yourself through a prototypical experience of his job than to ask him what he 'wants'. Most of the time, he doesn't know.
1. Programming in Pascal is better than in C++ because compilation time is shorter
2. Knowing mathematics very well is extremely important to become a good programmer
3. How fast you type defines your productivity
4. More features means better software
Things I learned after colledge (to my big surprise!):
1. On real project, coding takes 20% of time
2. There are people who test software, and they can find 100 errors after project is considered completed by developers
3. Less features means better software
1. The goal is the only measure. Maintainability? Who gives a crap about that.
2. What the hell was the point of making us program using punch cards? Come'on!
3. Raw cookie dough and Mountain Dew can fuel some seriously productive coding sessions into the wee hours of the morning.
After:
1. Sucks having to maintain other people's crappy code.
2. Team dynamics are so important. Like marriage when it is good it can be really good but when it's bad - ouch.
3. Raw cookie dough and Mountain Dew will eventually catch up to you. :-(
1. The performance gains of various sorting algorithms (ex. Bubble Sort, Selection Sort)
2. Utilizing an IDE is much quicker than Notepad and cmd.exe.
3. Adding extra people to a project that is behind schedule, will not prevent it from being behind schedule.
After:
1. .NET is the best!
2. "There are 10 types of people. Those who understand binary and those who don't." - source unknown
3. Adding extra people to a project that is behind schedule, will not prevent it from being behind schedule.
1. Being a code monkey can mean good money for beer.
2. Always charge by the hour for your services.
3. If you do not deliver on a deadline you a in a mess.
4. SmallTalk is a fun language
Things I learned outside of College
1. Hired for maintanence = Lots of headaches
2. Detailed Design is a huge plus for work
3. When you estimate leave room for something unexpected.
4. Microsoft Access can reach 2 GB in size and seems to be the users favorite way to do everything.
Sorry I kinda went over 3.
In Uni
1. I never knew I could go so long without sleep and spend so much on beer.
2. Your work on a brand new system from scratch every 6 weeks .... and then it goes in the bin.
3. If you want to pull in a club, never mention you're doing an IT degree, just lie. My personal favourite was "... I'm studying third-world agriculture and finance". :)
In Work
1. There's an awful lot of monkeys out there and a lot of them are contracting.
2. Just because you've found the "save to web" option in MS Word doesn't make you a web designer
3. Leaving work at 5pm (or 8pm if you work in outsourcing) and going home with no more work to do and just vegging watch telly .. rocks !
4. [Sorry I'm on one now] Your work on a bag of cr*p that's had 10 different developers working on it in the past 2 years and it's still more rewarding that assignments because it actually gets used !
The best coders I've seen in my whole life (including me) does in fact have NO formal education what-so-ever...
In fact a friend of mine which only has 9th grade does on a daily basis teach ASP.NET, C#, VB.NET, Design Patterns and "you name it" to Master Graduates and he's on a 9.98 in average score out of 10 possible and enjoys SERIOUS respect from all of his "students"...
For us (in our hirings) it's an advantage NOT having education since that means you're really serious about the stuff you know and you have 100% pure dedication in learning...!
I think those that's great programmers and have education more are great DESPITE of having school than BECAUSE of having... ;)
.t
In school:
1.) Whether something is correct or incorrect depends on the instructors interpretation of the subject matter not the actual correct answer.
2.) Professors base a lot of things on their opinions not any basis in fact.
3.) Math professors tend to be a lot more grounded and without bias then say, English Lit professors.
After school and after 10 years in the GIS and CAD and embedded systems industry:
1.) You will use every piece of Geometry, Trig, and Calculus you ever learned in school and still need to learn more.
2.) You will need to use every trick you ever learned for speeding up calculations in school because geometry is hard and if you don't know this stuff your software can literally take days to execute instead of seconds.
3.) Understanding how computers work is essential, especially where it concerns floating and fixed point math.
4.) You will use C, C++, and Assembler nearly every day of your career so you really need to understand them.
5.) Walk through every piece of a new systems design with as many people as you can find and be ready to listen to criticism because mistakes you don't fix at the design stage will become incredibly difficult to fix once the system has been coded.
6.) Developers who work on other types of systems such as medical, financial, web, etc. are never going to get what you do and won't get why you think certain things like pointers are important for developers to know. But you can learn a ton from them on how to design good user interfaces.
7.) Things developers think are intuitive are generally completely opposite from what a user will think is intuitive.
8.) Code like you will have to maintain it after totally forgetting what it does and how it does it. Because you will.
9.) You will very likely end up going back to school to take more math even if you minored in it.
10.) Keep the contact names and numbers of your math professors it can be a life saver.
After college: Programming is difficalt, if you want to do a good job.
A bit later: Programming is easy if you do it in Eiffel.
Never hire a programmer that went to college.
Degrees mean nothing. The actual ability to do it does.
College contrains the minds of programmers by teaching them what can't be done in a language, and professors are usually wrong.
College is for morons who never had the mental aptitude to begin with. They think going to school longer will magically give it to them.
Comments are closed.