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
Re: (Score:2)
Also, the book "The Clean Coder".
http://www.amazon.com/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073 [amazon.com]
http://www.cleancoders.com/ [cleancoders.com]
Re:Reading List (Score:5, Interesting)
Add Code Complete to the reading list as well as The Pragmatic Programmer
Replace Code Complete with "The Practice of Programming" by Kernighan and Pike (yes, that Kernighan. Yes, that Pike) and you've got something. You can keep Code Complete for when you can't sleep (IMHO, YMMV).
Re: (Score:3)
It can be found online here: http://www.faqs.org/docs/artu/ [faqs.org]
One of my favorite parts is on transparency and discoverability: http://www.faqs.org/docs/artu/ch06s02.html [faqs.org]
Re:Reading List (Score:5, Insightful)
I scrolled down just to see if someone suggested Pragmatic Programmer, AC deserves a +1 billion mod. If you read just this one book, and apply it, you'll be head and shoulders above most of the industry in one foul swoop.
Secondly, you already know this answer by the way you phrase your question: Stop doing prints for debugging and use a debugger, that's it's job. You'll remove years of pain and anguish from your working life. Anecdotally: our "debug by print" hire gave up trying to keep up with the "debugger guys" after only a few months and left the company voluntarily, despite our suggestion that his debugging methodology is painfully slow.
Test driven development. Hackers say "but it takes more time to write the tests", I say: "But it saves me a butt-load of time tomorrow, it's a net win that will keep on giving". Moreover, TDD tends to result in cleaner designs anyway. I take this a bit further: If I have to write a new concept into a huge system, be it big or small, the first thing I do is write a smaller test with the new concept, iron out all the bugs and kinks until I understand the problem and solution properly, only then I dig into the "big code". Once again it's about saving myself time and headaches. (and, of course, try to write a module or component I could re-use in a similar situation)
Learn as much as possible about dependencies. Also the difference between library code and application code, and what bits of code go into which of these. (Pragmatic Programmer's "do not repeat yourself")
Basically your thinking has to shift from the short term to the long term: "I have to maintain this, possibly for many years to come, lets save my future self a lot of pain by doing some planning and doing things right the first time" (yet more pragmatic programmer).
Anything you get on this post though, is going to be a bit of a "learn C++ in 21 days" thing. We can tell you all about what we've learned and you can try to assimilate it all, but at the end of the day to get 10 years experience you usually need.... 10 years, but not the kind of 1 year x 10 experience lots of folks have. I found it very hard at first to "catch up" with mountains of information being shoved down my throat all at once, but...
Find a good environment above all else. Work with and for people who are highly experienced, highly critical, and aren't afraid to show it. Work with people who will gladly review all your code and blast it to bits for you. This is emotionally uncomfortable but pushes you up a steep learning curve very quickly. Programming can be a very social and cooperative learning activity in the right environment (look up agile while we're here). I'd say that way you can gain 2 years experience for every 1 on the job, possibly more. The trick is to tell the guys you shouldn't be listening to from the ones you should, and it may take a job-hop or two to find them.
Re:Reading List (Score:5, Interesting)
Debuggers work fine if you can run your code repeatedly. However, if you have a massive existing workflow that you're also supporting the tools for, then you want as extensive logging as is possible. This is also "debug by print". The big difference though, is that I can let it run all the time, and when something goes wrong, I can then pull up the log, and figure out what went wrong without having to start up a debugger, or redo the process at all... which is very important for intermittent bugs.
All that said, while I tend to eschew debuggers, and use "debug by print", both do not accurately describe the way I debug. I white-box debug code. That is I read the code and understand how it works. Sometimes, I need to know which path was taken or not, and I add debug printing lines. Why do I do things like that? Because I tend to work with virtualization and emulation, where in for example, I had a bug with an emulator that only manifest its behavior a second after the bad opcode was executed. With a ~4 MHz processor being emulated, that means that about 1 million opcodes had executed (~4 cycles per opcode) prior to the the behavior manifesting itself. The behavior also only demonstrated itself at least about 4 million opcodes in. It's a needle in a haystack to find the correct point at which to break the debugger, and intractable to step through the debugger.
Using a debugger is simply not always the best choice. It is commonly the best choice, but it certainly is not an omni-tool.
User acceptance testing (Score:2)
Don't worry (Score:3, Interesting)
Re: (Score:2, Funny)
Sorry, but we reserve the GUI design jobs for Monkeys and typewriters.
Re:Don't worry (Score:4, Funny)
Re: (Score:3)
It helps to understand what MCSE stands for: Move Computer Shit Everywhere.
We need a new one for MCITP since MCSE is pretty much dead - Must Consult Independent Thinking Person? Nah someone will do better than that.
And yes, I have those certs (and others), so I'm ... qualified to poke fun at them.
Re:Don't worry (Score:5, Funny)
MCSE: Minsweeper Consultant and Solitaire Expert
At least that's what I was always told.
Re:Don't worry (Score:5, Insightful)
Why is it people seem to think GUIs should be done by junior developers?
The front end code has to be the biggest pain in the ass out there.
Ooops I think I just gave away the secret.
Be a hacker (Score:5, Insightful)
Re: (Score:2)
Not only that, but the pure fact that he realizes that what he's been doing isn't exactly the same as what you'd do in a regular job means that after few months at a "real job", he would be well on his way on being an "engineer".
Huh? (Score:5, Insightful)
If you can actually design a solution, throw together a suite of unit tests (that ideally show the basic API,) and deploy it to production, you are already ahead of 95% of the "software engineers."
Re: (Score:3)
This.
The guy is describing a process that actually produces things that work.
He should just stick with that, adjusting as he goes and keeping an open mind. If a more complex process is needed to get a reliable and working result, it will avail itself.
Re:Huh? (Score:4, Insightful)
It's great to end up somewhere that wants you to lead the way forward, but even then you have to develop the social skill of bringing people along with you by earning their respect and trust. Most people want to see you "do it their way" first in order to prove yourself.
What do you think "engineering" is? (Score:5, Insightful)
An "engineer" is somebody who takes the time to understand a problem, and creates something to solve that.
Having done software from scales ranging from "quick shopping cart application" to enterprise scale organizational relationship management software, the only real difference between the two is that with the latter, you create a large number of smaller projects roughly the size of the aforementioned shopping cart application, except that the "users" are often other pieces of the same system. In larger systems, you'll be talking with other developers who have built or manage the pieces your parts will communicate with. You'll read more documentation, and it will be generally of higher quality than the shopping cart scripts.
Don't *ever* lose the "hacker" mentality - exactly what you described is what software engineering is. The toughest part IMHO is getting to an understanding of what the end user actually needs. That's far and away harder than all the other stuff, which boils down to implementation details once you understand the algorithms.
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.
Re:What do you think "engineering" is? (Score:5, Funny)
I would add that the big difference between "hacking" and an engineering approach is a structured understanding of the problem.
I may assume that the CS masters study has taken care of that "structured understanding" part. In other words: hacker + CS degree = software engineer.
Re: (Score:3)
I've never been so glad to see something scored +5 Funny. Gives me hope in Slashdot again.
Re: (Score:2)
Let me know when the IEEE has come up with a certification for software engineers, and I'll take it.
Until such time I'm going to continue to call myself a Software Engineer, because it's the title that one of the world's largest computer and tech firms gives me, and it's the role I perform.
MSCE et al (Score:4, Interesting)
I'm not an engineer. I used to be an engineer. I've worked in power stations, oil refineries, offices etc and helped educate engineering students at a university and been a member of IEAust and ASTM. However, due to a lack of jobs a bit over a decade ago and a career change now that I run the computer systems for a company and write a bit of code every now and again I'm not an engineer anymore. You can call yourself whatever you like and are perfectly justifed to use the title given to you but don't expect everyone to take it seriously, especially since professional engineers have a code of ethics that you do not have to stick to.
Easy: read the list (Score:3)
Don't take it from me, look up the website for any professional engineering body and see what the requirements are to join.
Nice little joke but I'm trying to be serious here.
Fair enough, but "I could have been a contender" does not equal champion even if the rules are skewed to unfairly keep you out of the ring.
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.
OK, just look at the et al not MSCE (Score:3)
Of course not since I know nothing about you and it's a conversation not a silly personal attack. I put it in the title because that's just another bunch of people using the title that somebody else (Microsoft) gave to them. It's an extreme that everybody knows even if it's not as bad as it used to be, just like the guys that run cables that get called "engineers" by their employers and then that title gets shoved down the throat of cu
Re: (Score:3, Insightful)
I'd upvote this more if I could. As someone who both codes for a living and hires engineers to do the same, what you are describing is exactly what I look for in an engineer. You can become familiar with more tools and methods, but at the end of the day, you [just] need to be able to solve problems well. The only additional challenge in the "real world" is breaking down larger problems, and solving them in "better" ways (ie: fits better with the rest of the system, is maintainable, is flexible, etc.).
What is an "Engineer" in the real world? (Score:2)
An "engineer" is somebody who takes the time to understand a problem, and creates something to solve that.
In an ideal world, you bet, the above is true.
But we live in the real world, and in THIS real world that we live in, there are simply too many people who call themselves "engineer" who never take any time to understand any problem
The many years I've lived in this real world tells me that I don't want to be known as an "Engineer" even when I am more qualified than 99.99% of those so-called "engineers" out there
Hacker vs engineer (Score:4, Insightful)
development styles (Score:2, Funny)
Learn to bullshit about development methods like agile, waterfall, etc. Learn to estimate project costs before a project starts. Expect to spend lots of time making these estimates without getting paid for them only to be told that your estimate is too expensive and you've been beat out by some 'hacker' from Asia or Eastern Europe where the cost of living is a fraction of yours.
If you play your cards right, you will graduate from programmer of the line to 'system architect' or something like that where yo
Re:development styles (Score:5, Insightful)
You know, things have changed in East Europe during last decades. Electricity 0.14 EUR/kWh here vs. 0.15$/kWh in USA. Gas 1.4 EUR/l vs 1$/l in USA (caused mostly by taxes but that doesn't matter). Chicken meat 2 EUR/kg vs 2$/kg in USA. House property 1300EUR/m2 in Slovakia [globalpropertyguide.com] vs 200$/m2 in USA [globalpropertyguide.com].
Perhaps I've picked wrong sources or wrong goods. I challenge you to provide your numbers and I'll tell you the prices here (where the average income is less than 800EUR/month). I'm damn sure, that cost of living here is NOT a fraction of cost of living in US.
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
Re:Try to get a real engineer as mentor (Score:5, Insightful)
Meh.
Which came first, the engineer or the engineering degree?
Re: (Score:3)
A masters in CS is just as valid towards a "software engineer" job title as a similarly focused degree from an engineering dept. Different schools have different organizational structures. A software engineering degree from a CS dept is no less valuable than one that comes with a ring. You should absolutely not equate a "software engineer" as someone with a ring. That's not to say that ring-based engineers can't be good software engineers. I'm not in any way saying that. I'm just saying that more software e
Predictability (Score:5, Insightful)
Being a software engineer instead of a hacker is all about predictability:
There's more to each of these items, of course, but it's all about making it simple (KISS) and predictable. This sets a software engineer apart from a mere hacker.
You get a job (Score:5, Insightful)
Even if you are just stuck debugging someone else's code (90% of what I've done over the last year), the process of doing that 1,600 hours a year will really improve your skills.
Re: (Score:2)
Truer words were never spoken.
Not sure (Score:2)
Stay as a hacker (Score:3)
for
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)
this is what you will be doing throughout your entire career. time constraints, budget constraints, legal constraints, XYZ constraints - there will always be something effecting you to have to do it the hack way.
GOF Design Patterns (Score:4, Informative)
Difference is level of detail and corner cases (Score:5, Insightful)
I think the main difference between "hacker" and "engineer" is the level of detail and concerns on corner cases that you want your code to be able to handle and/or tolerate. Having worked as an engineer for some years, basically I boil down the job to three things -- 1) good clear communication of what the problem to solve actually is, 2) solving the problem such that the solution "meets spec", 3) trying to make sure that the solution continues to work within tolerance in any typical adverse conditions the solution needs to handle. Occasionally you may need to do some kind of formal verification that the solution will be wtihin tolerance in typical adverse conditions. With programming this verification might involve a test suite, code review, fuzzy input testing, memory leak testing, security audit, etc.
But in your particular situation it sounds like you're going to learn what you need on your own on the job one way or the other, so for now I'd say just relax and figure out what you need when you get there. i.e. I think you might be over-thinking this right now. ;-)
Aesthetic Sense (Score:2)
This is purely anecdotal experience, but people from academia tend to write code that is a bit more "ugly" than seasoned "software engineers". By "ugly", I mean the code works, but it's relatively less readable and harder to maintain and extend.
Other than that, it's pretty much the same thing, IMHO. There's nothing so magical/mythical about "software engineering", and practices between companies can be very different.
Re: (Score:3)
Sadly I think there is some truth to this.
Writing clear, readable code that was modular and extensible doesn't mean too much in the academic world (unless writing the code in that way is your primary reason for writing the code).
Looking back at some of the code I wrote as a student, as well as code from other students and faculty members that I encountered I have to admit that there was very little future-proofing involved. Rewrites were very common (due to code often being written to just do one thing).
Not
Re: (Score:2)
By "ugly", I mean the code works, but it's relatively less readable and harder to maintain and extend.
Hate to quote myself. I'm violating my sig.
Empathy (Score:2)
Get a mentor (Score:5, Interesting)
Find someone in your new office to show you the ropes. Every major piece of software tends to have its own issues. For server software you might be looking at analyzing piles of log output. For gaming it might be real time perf metrics. Chances are, the biggest thing to get comfortable with is your debugging->fixing->building->testing->checkin cycle. Make sure you figure out how to get the road blocks out of your way. If you're working on something painful where there's a ton of time wasted rebuilding to try out your ideas, maybe there's a better way to build/patch in a more granular way. Your peers will also be interested in any process improvements. If you can optimize and speed up a process that makes you more effective, share it with the team. People really respect and appreciate anyone who can make their life easier.
And *really* spend some serious time trying to learn your software's object model, lifecycles, and data structures. When you start there will be an overwhelming amount of information. You need to accept that. But once you've got a bit of a foothold, CONTINUE learning. You want to be an expert. It takes discipline to get a broad and deep enough understanding to truly be efficient and effective. Be interested in the work of your closest peers. Chances are, what they have learned over the years can be incredibly helpful to enhancing your efficiency. At the end of the day, you'll be primarily judged on reliability and throughput. Whatever you can do to meet your goals, the better! And never be afraid to get help. It doesn't matter if someone helps you finish something. All your manager cares about is that the task is done. If they assign it to you, you are responsible for driving that task to completion. If you don't have an a clear idea of how to do something, that's your cue to immediately find someone to brainstorm with.
And career-wise, it's easier to advance in the earlier years. So when optimizing towards success and a happy retirement, a lot of it comes down to how quickly you can advance in your early years. Down the road, it's as much time as ability. To start with, it's all work ethic. Put in that extra 10% to be the hardest worker and you'll be getting promotions year after year. Work through those lower levels as fast as you can so you can enjoy the rest.
Good luck :)
Hacking and Engineering (Score:5, Interesting)
Engineering a house:
1. Gather requirements
2. Write a spec
3. Design house to spec
4. Build house to design
Hacking a house:
1. Nail boards together
2. Step back
3. Is it a house yet?
4. No, go to 1
Both methods work, but I'd prefer the former to the latter...
Re: (Score:3)
And professional software development is usually more like the latter than the former.
Re: (Score:2, Funny)
LOL
The big difference with house vs. software is that when you nail some boards together it's quite permanent, and hard to remove and redo. I admit to do programming mainly alone the second line, but usually with something like a plan, and working quite targeted to it. More like:
1. Nail boards together.
2.Step back.
3. Location correct, all straight up and aligned with the rest? goto 6.
4. Redo latest board, and/or adjust previous boards.
5. goto 3.
6. Looks like a livable house? end.
7. goto 1.
But then without
Maintainability (Score:5, Insightful)
I'd say your number one goal is (Score:3)
Learn to read code (Score:4, Interesting)
Welcome to the farse of "Software Engineering", the sooner you realise that the way things happen in the real world is just (as you say) hacking stuff together and debugging it the better. The only added fun that you will have no idea what 70% of your codebase does and neither does anyone else.
While Software Engineering never provided any credible way of _building_ the systems, what it used to do is provide ways where you could find out exactly what you need before you start building it. These days we have Agile instead, so we don't do that, we just pick an idea at random and hope to god it's either right or we can change it.
My advice: Learn to read code. Learn to find out what the system actually does, not what the comments says it does. Learn to read it then work out how to slowly change it into what you need. It's the difference between the respected senior guy who fixes the problems and the detested junior guy who creates them. I work with a commercial 3D game engine and the fact I know every line of it is worth far more to anyone than how many lines I can myself write in a day.
Testing and readability (Score:3)
You say you've done some "basic" testing, but one of the biggest challenges for me upon entering a "real" software development role was adapting to test-driven development. Even if you don't take this all the way and write up all of your unit tests before you start coding, you do have to completely re-think how you structure your software so that it can be testable at all. This means breaking up your functions not just into parts that make it more readable, but into parts that can be independently tested. Usually this means breaking out your dependencies into interfaces, so that they can be mocked out (oh, and learning how to mock things), avoiding side effects, that sort of thing.
Also focus on writing readable code. I usually make one or two passes after I think I've gotten everything written and refactor with an eye toward making everything readable and understandable.
all making sense until mythical man month (Score:3)
That's more of a management book. If you want to get better at coding practices, you want a different library entirely. Try reading something like code complete or refactoring to patterns.
Agile vs. Waterfall (Score:4, Insightful)
Your contrast is not really hacker vs. engineer, but agile vs. waterfall.
If you think building software is like building a building (spec it out in detail before you start, write tons of documentation, resist any change orders)--that's "waterfall" methodology, what you are referring to as "engineering."
If you want to start with a software sketch, show the sketch to your customer, and then incrementally improve it until the shape develops into something really useful and valuable--that's "agile" methodology, what you are referring to as "hacking."
Both are totally legitimate forms of software engineering. But waterfall-style "engineering" is cumbersome, slow, extremely expensive, and tedious. If you love programming, pick a small company with an agile mentality. I've done both styles, and I don't ever want to work in a large software shop again!
Re: (Score:2)
Disagree.
In fact, I'd actually say that the terms engineer and hacker are somewhat orthogonal.
How much of a hacker someone is is a matter of passion.
How much of an engineer someone is is a matter of discipline.
Are you asking how to get more consistent results? (Score:2)
setting good deadlines and meeting them?
Happier users?
There are lots of different software development "methodologies". To me that's what you're talking about. Which one is right for you depends on a number of factors. Whatever organization you end up working for might already have one and your job will be to learn it. If you're in a position where you are the one to decide what your process is going to be, then you've got some research to do.
Not all methodologies are appropriate for all a
Engineer (Score:4, Insightful)
The biggest problem most techs face is their own arrogance. Your desire to mature as an engineer sets you apart from many of your peers.
Perhaps on a more practical note, I'd suggest that you plan to spend six months to a year working in a beauracracy nightmare shop (eg a bank).
If and when you come out of the end of that experience, you will be much better positioned to apply the theoretical knowledge, and you will also be sufficiently jaded with process overkill.
However, my strongest suggestion would be to keep doing what you're doing. Allow a little time each week to continue developing your expertise. That habit distinguishes the masters from the journeymen.
Re: (Score:2)
> The biggest problem most techs face is their own arrogance.
Bingo. Don't look down on your peers. You are not better than them just because you like vi.
Engineer's solution (Score:2)
Coding practice (Score:2)
I think experience on commercial projects allows you to develop better coding practices and develop skills for estimating project size. It usually takes 6 months to a year for one of our fresh masters level graduates to become fully productive.
At our company, we won't hire you unless we are pretty sure you can do the job. It is our responsibility to make sure you learn the skills to be productive.
Test Driven Development (Score:3)
You have to specify SOFTWARE engineer (Score:5, Funny)
So you don't get confused with a real, actual engineer.
Re: (Score:2)
Agreed, I prefer to call myself a Software Alchemist.
Re: (Score:2)
My boss used to call me the evil wizard, does that apply too?
Have one such case right now (Score:5, Interesting)
I have a hotshot hacker working for me right now who thinks he knows everything, but he is just a stupid little hacker who thinks his dick grows every time he uses vi. Don't be like that.
You are already on the right path: You recognized in yourself that you need to grow professionally and that you need to get away from the little dark screen and see how it fits into the world.
Three points:
* See the first for the trees
* Have the balls to say "I don't know"
* Education, education, education
Here is the most important thing to remember: A hacker sees his own little thing that he hacks on. An engineer see how that thing fits into the world and people who uses it. See the forest that your little tree grows in.
All companies and industries have standards, habits and a culture that it uses and the people are almost always NOT used to or interested in the little details that fascinate a hacker.The people out there will not change their entire culture to fit your hacking needs. The job of any technology and the engineers that build it is to facilitate the and simplify the lives of other people.
Professionality means that you take responsibility for your work. That includes taking responsibility for the interface to the users.
Read this:
The Clean Coder: A Code of Conduct for Professional Programmers (http://my.safaribooksonline.com/book/programming/9780132542913)
Number two: You cannot know everything. Accept it.
There is nothing wrong with expanding your horizons and going past your field, but when you are in a terrain where you are uncomfortable make sure your peers know it and make sure you have a mentor and listen to him. Or delegate to an expert. People will have a much higher esteem for you professionally if you have the balls to say "I don't know" instead of lying. It can be hard sometimes, but it beats being known as an arrogant little know-it-all.
Point number three: Education, education, education. Always assume you know nothing. Read up about your industry outside of the computer part. Computers are just a tool to make the gears turn. You will be a much better engineer if you know what the gears look like.
Good luck. You already took the first step and you will make it.
Dealing with people (Score:3)
do what you're good at (Score:2)
If you're good at something, enough that someone will pay you to do it, then go for it.
We need some people with the "hacker" mentality, they're like the blueberries in a blueberry muffin. Sure, you can make a muffin without them, but it's just not going to be as good.
Re: (Score:2)
Sadly, managers would probably accept the muffin without the blueberries because it's cheaper and it kinda does the work (i.e. stuff you sufficiently). Sure, it would be better with blueberries, but ... well, there's a budget to keep.
Time. (Score:3)
It's all about time and experience.
As long as you know that growth is possible, and worth striving for, and keep that as part of your outlook, the maturity will take care of itself.
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).
en-gi-neer—n. (Score:2)
Engineering is sustainable problem solving (Score:3)
You've got three broad brush categories, though of course people are often some of each.
- Programmers code stuff. Whatever you tell them to. Sometimes you can give them a problem and they come up with a solution, but it doesn't keep the entire ecosystem in mind. Often don't understand what they're really doing. Drives me batty when they're called Software Engineers. /product/, even if only an internal product.
- Hackers solve problems using whatever means necessary, however ugly it is.
- Engineers are solving problems keeping all the tradeoffs in mind and considering that this is a
Here's an example: This week a customer asked me for a feature in some PC software that generates files for processing by the embedded system. I know the entire ecosystem, not just the PC part of it, so I was able to tell them it was doable, but would have these negative effects - I can get you something working in the short term with these negative side effects, but we can get rid of them in the long run if we do this and that. They thought it was more important just to have the feature in the short term to show off in the short term and would ask me to make the other changes later if the tradeoffs got onerous. Maybe they'll never need it. This was a good deal for them in terms of what was delivered for what they're paying for my time.
You mention testing, but that's not really engineering per se, just one of the tools in the belt. A good programmer would (and should) be able to employ testing where necessary. In this case I did only cursory testing because they needed it /right now/ and the demo files I provided worked and were sufficient to show off the feature. And of course I told them this. Now that there's some breathing room I'll add better testing, and more if they decide to move forward on it.
It's all about knowing your /entire/ system enough that you can weigh the risks and requirements properly. Sometimes we blow a risk assessment or the requirement is wrong or something else goes wrong (customers are often very bad at providing real requirements or information) but at least you started from an educated guess.
You're a hacker, that's a good start since you're focused on solving the problem, and that's crucial - programmers are often (though certainly not all) bad at that. You are almost certainly more creative than some engineers. But now you need to consider that the requirements and the environment may substantially change how you choose to solve the problem. That thing you did may work, but is it maintainable and sustainable, and will it survive foreseeable new requirements?
Another example: there's a place in one of our codebases where sometimes you're looking for a string in an array in user time (someone typed something). We don't bother to sort that. Who cares? It's 'instantaneous' for the user either way. Why waste the time and code and complexity sorting it? There's another case where we're constantly looking things up, on the order of 5x a millisecond, so that one is sorted. But not cached since 5x/msec isn't /that/ much of a hit in context
I went a bit long, but I hope this makes sense. It's all mindset. Engineering is learning everything you can that even indirectly effects your system and solving problems based on ALL the tradeoffs. Realistically you can't know them all, but you can try. Iteration helps, as does time and budget.
Yes that's it. (Score:2)
The most important difference between 'hacking' and engineering is understanding time, and understanding humans (epsecially yourself).
In a nutshell:
0) learn the difference between 'clever' and 'smart', and then 'smart' and 'wise'.
1) code is to your employer as mass is to an aircraft engineer: less is better.
2) understand how and when to say "no" to your management, or more realistically "how long" and "what it takes" and don't overestimate your total productivity in delivering product as opposed to a caffei
The difference between the two is (Score:2)
Sadly, you'll fit in perfectly (Score:2)
Don't sweat it. You'll be doing fine. It's commendable that you want to be better but yes, the "piece it together and keep compiling and building 'til it does kinda what it's supposed to do" is pretty much the approach (too) many programmers have to a problem. It's not your problem. It's an industry problem.
One thing university hardly prepares you for is the reality of programming. You won't start fresh with a project, at least your chances to do that are slim to nil. You will most likely be hired in the mi
Understand the problem. (Score:2)
Tight algorithms are nice to have for most of the people actually using software. Engineering is an applied science. Engineers solve real problems which means clearly identifying the potential for their investment.
Identify who is going to use the software. Who is this person? Put together a profile on a couple sheets of paper. Have a face for this person. There may be a few personas that will use the software.
Given these personas. How do they accomplish the task you intend to improve today? What is
more than coding (Score:2)
Software engineering is more than just coding and testing. It about getting exact requirements from the client; documentation and boring paperwork (always more paperwork!), collaboration, time management...
You could say software engineering is coding with the fun taken out of it. My advice: try to get a in house job in a tech firm, where the 'client' are technical people who know what they need, and to whom interesting problems and clever algorithms matter. That way you'll spend more time coding and less ti
Discipline (Score:3)
First and foremost, self-discipline. Yes, I know, it is hard.
Be prepared to go unrewarded for your "extra efforts" which are in actuality basic software engineering tenets.
Do NOT design at the keyboard. You can be agile without designing at the keyboard, you can be a traditional waterfaller without designing at the keyboard, you can be a spiralist without designing at the keyboard. When you find yourself making design decisions at the keyboard, unless they are truly trivial (and the litmus for this will change with experience) WALK AWAY from the keyboard.
Ensure that the people who assign you work understand the caveats of what they are currently asking you to do. Even if this makes people think you are being negative, give them the information they don't even realize they need to make better decisions. YOU are the expert on what will happen when implementation happens. For example, if your product manager or account manager or <insert PHP - pointy haired person - here> wants a milestone that includes features that are poorly defined (either through their own recalcitrance or through, most likely, a customer who doesn't know what they really want) it is your responsibility to be the a**hole negative nerd who makes it CRYSTAL CLEAR the implications of doing such a thing. That doesn't mean you don't do it, it means you sacrifice whatever small amount of political capital you have with them to ensure that everyone is on the same page about the potential outcomes. You're going to be shocked by what people can 'pretend' to not recall ;).
Think about problems in a fashion designed to allow for systemic flexibility because, just like in war, everything goes to plan until the first shot is fired.
Think about the long term viability and accessibility of the code you write (good variable names - really, I know you've heard it a thousand times probably, but it makes all the difference in the world.) When the choice comes down between 'clever' and 'clear', unless you have a really compelling reason to be 'clever' - go with 'clear.' The codebase isn't a place to show off your 'chops' - it is a place to think about all the people that will or may come into it behind you and they may be clueless or very inexperienced. Comment your code, another 'I have heard it a thousand times' one I know, but people just don't seem to do it because IT TAKES DISCIPLINE.
If you haven't done much with software patterns, pick up 2 or 3 books about them (both local and network patterns) because, although dry, they often contain the 'wisdom of the ages' for people new to software. Hell, just two weeks ago I was discussing a feature our Services team was implementing for a solution (I run Engineering, we produce products that the Services team [and external parties] uses to implement solutions) and they needed to simulate a physical machine. They were at a total loss about how to accomplish this (no snickering you experienced developers - especially game guys!) When I broached the topic of state machines they all went sort of glossy eyed (like some fish I'd just reeled up from 200 feet down.) After I explained for a few minutes I got a lot of head nodding. The next day I wrote up a little Java applet (yech) that demonstrated a crude approximation of the machine and used a state machine for managing it. Suddenly, everyone in Services is all about state machines (it is pretty funny actually - they have a shiny new hammer and they are wandering around looking for nails.)
There are dozens of things we could discuss but aside from the final thing I'll recommend below, remember, you don't want to just be a programmer (so it sounds) so to be a software engineer you need to have all the abilities of a programmer but also spend time thinking about the process, efficacy, flexibility, and extensibility of how you will implement solutions to problems.
The very last thing, and very important although many people who call themselves software engineers ignore it, is to be technol
Engineering is all about process (Score:4, Informative)
Don't engineer, become scientific (Score:3)
First off, there is no such thing as Software Engineering. Engineering implies replicable best practices to solve a common problem, e.g. building a bridge. There are standards, licensing, courses, and an apprenticeship which teach the standards and practices.
Besides, there are two possibilities in software, either the problem has been solved or not. If it has been solved then just buy it. Don't reinvent the wheel. If it hasn't, then you are in the world of research and development. This is where the science comes in. You have no real guides, so you start by sketching out a proto-type. You then try to implement it and test it all the way forward. It's the hypothesis/experiment approach. This is why testing is so crucial in software development. If it doesn't pass the tests, try something different.
Engineering implies canned solutions. In full scale software development there are no canned solutions.
Re:srsly (Score:5, Insightful)
>nobody in the 'real world' is any different
And the public wonders why most software is bug-ridden, badly designed shite.
Re:srsly (Score:4, Interesting)
I'm a software developer by trade, and I'm also old enough to be of the generation where one has pride in one's work but, in my experience, many places where I've worked don't seem to share that same pride in a job well done. Most care far more about getting something, no matter how "bug-ridden" or "badly designed" out of the door so they can bill the customer.
I always remember this quotation from the great Niklaus Wirth [wikipedia.org]:
In a well known interview with Dr. Carlo Pescio, published in Software Development, June 1997, Pescio asks Wirth:
You probably know about the 'good enough software' concept popularized by Yourdon. In many senses, it's just a rationalization of what's happening in the software world: the first company hitting the market with a feature-rich product is more likely to win the battle than the careful, quality-seeking company. Do you think there is anything developers and software organizations can do about that? I guess many developers would be happy to be given more time to develop better software, but at the same time they are rushed in the name of corporate survival. 'Educating the users' seems more a wild dream than a possibility.
to which Wirth replies:
'Good enough software' is rarely good enough. It is a sad manifestation of the spirit of modern times, in which an individual's pride in his/her work has become rare. The idea that one might derive satisfaction from his or her successful work, because that work is ingenious, beautiful, or just pleasing, has become ridiculed. Nothing but economic success and monetary reward is acceptable. Hence our occupations have become mere jobs. But quality of work can be expected only through personal satisfaction, dedication and enjoyment. In our profession, precision and perfection are not a dispensable luxury, but a simple necessity.
Re:srsly (Score:5, Interesting)
"with proprietary closed source software [...] compared to the FOSS model"
I think you are mistaking possibilities with realities. Yes, open source has the *potential* to more eyeballs but then, all so much FOSS projects have are the two eyeballs from its only developer. Yes, FOSS has the potential to get rid of absurd timelines but then you see so many projects that deliver on a deadline, ready or not ready, or answer you about a bug report with a variant of "I don't have time to deal with old bugs, I prefer to expend my time on more bug-ridden features". Yes FOSS is not necesarily driven by maximizing profit, but they aren't necesarily driven by its quality (i.e.: they can be driven by it fun factor).
"because there is no profit"
Who told you that? That's obviouosly false. They can and certainly are for profit in a lot of situations, it's only that their revenue stream is not on selling use licenses but in the development fact itself (features on demand; I worked for a company like that -the problem is when this becomes a freemium model where known to be necessary features are not developed unless something pay for them) or in installation and support (and then it can be possible that never good install procedures or documentation will ever be produce).
"I wouldn't call it "hacking" though. I think its actually called "extreme programming" or "agile software development". "
But then antifoidulus is right: hacking something together and pushing it into production is, well, hacking and certainly has nothing to do per se with extreme or agile programming. Your approach can lead to a good solution (if the problem realm is not so difficult and you are good at it) as well as to a fast pile of shit that only worses as time and feature crap goes by. As such is the opposite to engineering, which is about insure the results.
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.
Take a Test. (Score:2)
Take the FE (and the Canadian/European) Equivalent and tada. You can call yourself an engineer.
It would help... (Score:3)
How about target space: mobile? embedded? cloudy? big data?
(Tool sets & technology stacks don't matter so much, you'll find those are the easiest part to wrap your head around.)
In any event, congratulations & good luck!
Re: (Score:2)
I didn't spent years of my life studying "to put food on the table" - I studied and became an engineer because of my passion for technology. In other words, I love my Job and I love developing software.
The "so called" engineer would actually know that methodology and testing not only doesn't have nothing to do with engineering, but instead knows that these are (some of many) tools with which to produce quality solutions.
Re: Engineering (Score:5, Interesting)
Yep, with most of the big engineering firms I've worked for, it's maybe 5% hacking and 95% documentation and packaging. If you can enjoy doing mostly the latter (finishing the last 10% of a project that ends up taking 90% of the time), then you should be able to get along fine. If you spend all of your time doing the former, then you will quickly become reviled by your co-workers :-P
Here's the junk that seemed important to engineering companies:
So, in summary, if you can find your way around some sort of toolchain that involves doxygen, mercurial, make/ant, cobbler, jenkins, and redmine, to the point that you can hand a junior engineering a piece of paper (oops, I meant email a link to a desktop instruction) such that the junior engineer can build their own working copy of the product by themselves with nothing but cold iron and a revision tag, then you're doing well.
But really, the real trick is to figure out how to get everyone on the project team to use the same toolchain :-P
Re: (Score:2)
Also read The Clean Coder: A Code of Conduct for Professional Programmers [safaribooksonline.com]
Re: (Score:2)
I agree. Using printf debugging is just one of many tools for trouble shooting. It's not the end-all-be-all but nothing is. I tend to flip between printf debugging and full JTAG remote debugging with very little in between. (nothing against application debuggers, they can be another useful tool)
Prints can add delays in a program and made race conditions disappear, which can be quite frustrating. But I also find fancy debuggers add unusual behaviour to a program which often result in tracking down some inacc
Re: (Score:2)
If you fix every problem with printf debugging you are likely to waste a lot of time when you are solving problems that are easy to solve in IDE debuggers. Sure, I still fall back to printf debugging when its the best tool for the job and sometimes its really the only tool for the job but its only one tool.
Really the best advice might be to understand how to use tools. I don't mean go out and learn every tool you can, or master one IDE and source control system. I mean try to understand how IDEs and debu
Re: (Score:2)
I'm not sure you're entirely on base, but you've got the right idea.
If OP wanted to take software engineering, he should have taken software engineering, not CS. They rely on much the same in basic skills but they are different things. A MSc in comp sci isn't supposed to be a programmer who's taken 10 extra courses. You're supposed to actually do, well, science. It is real work, it is the technical architect behind the system, the technical director who figures out what problems can be solved by the tec
Re: (Score:2)
I second this, the trick is to STOP and THINK. But get ready to fight for the privilege.
Many managers will just be fine with the hacked together solution and will probably complain about:
Don't let them bog you down, they're wrong although in their defense they simply can't see the difference and it doesn't matter to them. Besides, a properly engineered solution will not introduce the sort of design is
Re: (Score:2)
The problem is that managers want a shoe box, engineers design a shoe box and hackers then sit there and ponder how to fit a TV into it when the manager changed his mind.
Re: (Score:2)
That's why you have the manager sign off on the requirements and functional specification. He can change his mind (and often does as a company better understands the market) but the cost is then his responsibility which he can balance with the potential reward in his decision and communicate a justification to stake holders. If you just make the box, the responsibility is then fairly yours. How was the manager to know the cost of his decision?
Re: (Score:2)
I pride myself on being an engineer. And I absolutely love my work.
I coded professionally for years before I got my degree. But it took time, and a certain amount of formal training, to truly mature into an engineer.
These days, I play with some pretty big toys. And there most certainly is a part of me that's still a hacker. But that part is very much directed and disciplined by the engineer part of me.
As a result, I still get the joy of building things - at the code level, and at the architect level. T
Re: (Score:3)
http://www.joelonsoftware.com/articles/fog0000000069.html [joelonsoftware.com]
'"requirements -> design -> detailed design -> code" waterfall fails hard when at the code level you notice the requirements can't be met with the api's available. that's why at the requirements stage you should test that you can actually fulfill what you're promising to do. now a true agile design end result is that the test if it can be done ends up as the production version....