Ask Slashdot: Transitioning From 'Hacker' To 'Engineer'? 446
antifoidulus writes "I'm about to get my masters in Computer Science and start out (again) in the 'real world.' I already have a job lined up, but there is one thing that is really nagging me. Since my academic work has focused almost solely on computer science and not software engineering per se, I'm really still a 'hacker,' meaning I take a problem, sketch together a rough solution using the appropriate CS algorithms, and then code something up (using a lot of prints to debug). I do some basic testing and then go with it. Obviously, something like that works quite well in the academic environment, but not in the 'real world.' Even at my previous job, which was sort of a jack-of-all-trades (sysadmin, security, support, and programming), the testing procedures were not particularly rigorous, and as a result I don't think I'm really mature as an 'engineer.' So my question to the community is: how do you make the transition from hacker (in the positive sense) to a real engineer. Obviously the 'Mythical Man Month' is on the reading list, but would you recommend anything else? How do you get out of the 'hacker' mindset?"
Reading List (Score:5, Informative)
Add Code Complete to the reading list as well as The Pragmatic Programmer
Good Start (Score:5, Informative)
But really, that's for project management.
1) Go read up on the industry standard IDEs & debuggers for the programming environment you will be working in.
2) If your job is really consistent and stable (ie: Java programs day in day out), then go master your IDEs & debuggers. Learn their customization capabilities.
3) Learn to organize your personal code library and build up your core tool set in a way that is functionally reusable and searchable.
4) Learn to program your work in a way that adds to and complements #3.
5) Learn to document your code and processes.
6) Read a book on communicating to management (sry someone else will need to provide a good example), this will set you apart from your companions.
I meant to give you my 2 cents, but dropped a nickle... keep it. Good luck.
Try to get a real engineer as mentor (Score:2, Informative)
Well.. You need to find some real good engineers to work with and learn from them. :)
There are a lot of good coding examples open-source (Linux kernel) and you can learn from them too.. Practice makes things perfect.. Practice good coding habits.. Think more, code less, debug less. :)
Good luck..
~Self-learned Jack of all trades
GOF Design Patterns (Score:4, Informative)
Re:What do you think "engineering" is? (Score:4, Informative)
I would add that the big difference between "hacking" and an engineering approach is a structured understanding of the problem. (As several people pointed out, you actually need an engineering degree and possibly a certification to be called an engineer.) Part of that involves using standard and well understood processes for problem solving, inventing and documenting new repeatable processes, measuring performance, and using that to inform the continued development of your processes.
First off, a rant (Score:4, Informative)
A masters degree in Computer Science builds upon the basics of theoretical CS (theory of computation, languages, grammar, logics, discrete math...), technical CS (microcontroller, assembly) and applied CS (functional, OO and logic programming) from a undergraduate CS degree and extends it with topics about Networks (Sockets, Protocols, OSI Layers, Routing), AI (both classical AI with logic, planning and formal systems as well as machine learning), Operating Systems (for instance reimplementing parts of and studying Tannebaums Minix, Filesystems), Databases (Tuple relational calculus, OO databases, inductive databases, knowledge discovery) and also, and this is what I think you definitely missed out on, Software Engineering. This would involve developement models (V-model, Waterfall, extreme programming), UML, testing, maybe software verification, refactoring and so on.
Note that there is not much hacking (in a positive or negative sense) involved here. Great hackers do not necessarily need to be computer scientists, and competent computer scientists definitely do not need to be or leave the university as any from of hackers (be it some low level C pointer wizards or some OS file system experts).
I think what you meant to say is that the university did not teach you how to code in an industrial/enterprise setting. And rightfully so, thats the job of a vocational/trade instituion, but not of an university.
However, let me give you some pointers that helped me to grasp a bit more beyond purely academic programming.
1. Patterns. As some others have pointed out, this pretty much a must to grok in any OO project. The Gamma book is good, if you are looking for some really good intermediate more applied Java book about this, Effective Java by Joshua Bloch (he developed, among other things, the Java Collections).
2. Revision control management. One word: git. Anything beyond toy problems should not be touched without revision control. Watch the video with Linus Torvalds (the creator) to get motivated: http://www.youtube.com/watch?v=4XpnKHJAok8
A pretty good git tutorial that I like can be found here: http://www-cs-students.stanford.edu/~blynn/gitmagic/ch01.html
3. Read competent peoples code of the language of your choice! github and gitorious are a real treasure. The more you do it, the more you will discover more efficient approaches of how to implement certain concepts. And you will also see a lot of bad code and learn how to spot it.
4. Testing. JUnit is pretty basic to grasp. Some people swear by TDD (test driven development, write the test case first and then the implementation of what to test), I find this a bit extreme, however unit testing is a must to know.
5. Program yourself! Pair programming can be very helpful if your mentor is knowledgable and able to teach, otherwise do it yourself. Do not hack for the hell of it (although it can be fun), but focus instead on clean and clear concepts that you want to implement and improve upon. And document your code (doxygen or javadoc are your friends).
Re:srsly (Score:5, Informative)
He means running it and seeing what happens by adding lots of System.out.println();s or whatever the language of choice equivalent is instead of using a debugger. Well, I assume that's what he means.
Re:MSCE et al (Score:4, Informative)
This may be true in other parts of the world, but where I live in the province of Quebec, Canada, you CANNOT give yourself/use the title of engineer unless you are part of the Order of Engineers of Quebec. Other place may have similar laws.
Engineering is all about process (Score:4, Informative)