Slashdot Mirror
Ask Slashdot: Transitioning From 'Hacker' To 'Engineer'?
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?"
the heck are you talking about? nobody in the 'real world' is any different. hacker? give me a break dude.
Add Code Complete to the reading list as well as The Pragmatic Programmer
Other than possibly a more thorough job of testing, the only thing I would add is user acceptance testing. Does the program do what the user thinks it should?
If I used a sig over again, would anyone notice?
Don't worry. You don't seriously think you'll get to do any "software engineering" when you start, do you. You'll start -like everyone- programming fontends/GUIs, and let the more interesting parts to the more senior people.
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
I'm not sure you should try to get out of the 'hacker' mindset. Iterative innovation and continuous integration is much more rewarding than any waterfall approach. Good luck and follow your heart.
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."
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.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
I never considered the two to be mutually exclusive.
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 you tell other programmers what to do.
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.
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
The only thing left is learning whatever ideology your boss at your new job touts as the greatest thing ever. Then doing what you already do, but within his crappy box.
there are so many tools, technologies, dev environments, methodologies, languanges, operating systems... just don't sweat it. Keep your mind open and be curious, never assume you know all there is to know. Learn your debugging tools really well and find mentors for engineering *and* career questions (thank you Greg Berg). When you get to be a crufty old code, give some back and be one of those mentors.
Companies are looking for young programming talent with a generational affinity toward social networking, mobile technology, games, etc, and easy ability to dive into diverse programming languages and toolsets and get things done. Your academic CS background will be valued, too.
You'll pick up the software engineering and best practices stuff in your few years on the job. They're important, but that's usually not what you're expected to provide as a freshly minted college grad or masters degree holder. Just tell the interviewers you realize that it's very important and you will work hard to learn that stuff on the job. Oh, and you're willing to do whatever it takes - write shell scripts and unit tests, kick off builds every night, etc. They love hearing that from young applicants.
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.
The difference between a programmer and a software engineer are years of experience doing the work. I haven't yet met someone who graduated from school with a degree in Software Engineering whom I would call a software engineer. Don't sweat it one bit.
For experience, there is no substitute for working 8 hours a day, week after week, trying to write programs and make them better. Always be thinking about how you can improve the program you are working on (even if you don't actually have the time to do it), and you will quickly improve.
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.
"First they came for the slanderers and i said nothing."
Well, other than know your shit and stop whining, I don't know. You haven't said what your title will be or what you will be doing. Maybe by learning operations as much as you can and about how things work today rather than try to design new pie in the sky systems. Everything needs to be gradual. Also, learn how to document for gods sakes. Try to keep things simple, yet effective. Re-use proven concepts. Managing projects is always a trade off a effectiveness and efficiency, many people forget when they design a new system how inefficient it will be for the rest of the company or systems to do their jobs with the new system. Those designers are assholes.
Also, most of the technical "principles" and "distinguished architects" designing systems are pathologically overconfident in themselves. You'll be implementing their ideas for many years to come anyways.
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.
Read radical news here
By graduating from 'hacking' something together I'll assume you mean developing some rhyme and reason to your process, which honestly extends from experience and the design rules your employer gives you to code. Most companies have a specific design process, some more rigorous than others, the extent of what and how you are allowed to place things together and what sort of testing is expected should be laid out there.
Building a prototype by the seat of your hacking pants is one thing, working in start ups and corporate IT departments does require you to get serious and drop the hackery and adopt a professional attitude towards software development. Become an engineer committed to the design of the system that works for your client's needs.
You'll of course, at any company where work has been done, discover that hackers have already been at the company likely creating a mess. One thing that successful software engineers do is clean up the hackery messes by organizing the systems they left behind. When creating new systems that are to last a long time then organize it the best that can be done with a sane and clear design to get the job done and make it easy to maintain and grow.
It's not that you'll never use hacks along the way but it's best to never put those into production code. It will likely come back and bite you and the client more often than not.
Testing Suites help a lot. Create them. Use them.
Oh, get really good at debugging the systems. Listen to other people. Ask them questions. Be humble when you don't know and thank people for assisting you. It pays off and makes you indispensable.
I'd recommend reading the classic software design book Design Patterns by the "Gang of Four" (Gamma, Helm, Johnson and Vlissides). I know that "design patterns" has become something of an overused buzzword, but that book is without a doubt one of the best books about software architecture I have ever read. It helps you learn how to think about designing object-oriented software in ways that result in re-usable, understandable code. I don't think I really saw the power of good object-oriented design until I read Design Patterns.
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. ;-)
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.
Don't quote me on this.
When you work in a team, try to put yourself into other people shoe to try and understand how they see the project you are working on. This will let you learn about how software is perceived by others and the place it has in a business environment. It will also teach you to play nice with others, which is a great quality.
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 :)
Fuck it. The day programming is reduced to a discipline, where you can follow some process outlined in a three-ring binder or a management book-of-the-month and turn out product like a bricklayer turns out walls, is the day there's no point in being in it any more. Hell, when it gets to that point, the last programmer can just write some software to automate the process. Keep on hacking.
Read *lots* of code. On the job is a perfectly good place to do this. .....
Bad code.
Worse code.
Code that makes you laugh out loud
Check with others and see if they laugh too.
If they defend it, listen critically to what they have to say.
If they laugh, then don't write code like that.
Teach others how to not write code like that.
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...
To put a witty saying into 120 characters, jst rmv ll th vwls.
Ignore the assholes. Debates about the meaning of 'Engineer' aside, what you really need to learn is maintainability, testing, and patience. Writ code that you wouldn't mind maintaining if you weren't the original author. Don't repeat yourself. Follow coding standards. And most of all, learn to work with others and leave your ego at the door. That's what separates a 'hacker' from a professional.
To make your code readable. I mean so that if you came back to your code in 6 months you wouldn't have to completely reverse engineer it to figure out what it does.(Since I'm guessing you effectively threw away any coding efforts you did for your projects about 30 seconds after it got graded.) If you write your code with that in mind after a while you'll be fine.(Because believe me, either you'll be coming back to your old code or you'll be coming back to somebody else's old code and it sucks when it looks like the app was put together with figurative chewing gum and duck tape.)
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
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.
When Argumentum ad Hominem falls short, try Argumentum ad Matrem
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.
In Canada, you can't call yourself an "engineer" unless you have the academic degree that designates you as such. The PEng designation is only given if you actually got an engineering degree, and without that you are not really an Engineer. The local professional organizations for each jurisdiction might also oppose your use of the title. The justification for this is 1) to ensure that all people who call themselves engineers can actually be trusted to do good work, and 2) to that engineers can be self-regulated to remove dishonest and/or incompetent engineers.
Now, if you want to call yourself an software engineer, without the PEng designation, then you're still not really an engineer... Might I suggest "Programmer" or "Technology Specialist" or some other generic tech-related title? The other option is to get a proper degree in software engineering, so you can actually call yourself a software engineer, and be recognized as such.
That's right, finish the job. Yes find a way to incorporate what you like to maintain job satisfaction, but your main role is to deliver, if you expect checks to not bounce. That's the difference between a pro and a dilettante.
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.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
Sounds like you have a semantic crisis.
I was once nearly worked at 3COM, the project was a joke, I mean 10 people working on a crap design that one person could have done in a week a lot better (think hierarchical network nodes shown in flat lists because none of them new how to make a list hierarchical, or that you add a node in 3 steps but delete it in 1 since you needed to manually specify the parent node each time). I decided to excuse myself from the project as soon as I saw it. The programmers said I was a hacker (he said it as an insult), and I said "yes I guess I am", when actually I would like to have said "you guys are an incompetent bunch of useless idiots and if the rest of 3COM is like this then you'll fade to nothing". But I just wanted out of there, it was easier to say "I'm not good enough for your project" than to say "are you seriously this incompetent?".
What software engineering is, is what you describe as hacking, and what management consultancies claim software engineering is, is what you read about in these failed projects that take 10 years and end up cancelled. There's a lot of bullshitters in IT that never deliver anything working, but talk a lot who'll call you a hacker.
Testing is not your department, you cannot test your own work because any assumptions you make you repeat in the testing process. It does not diminish your role that nobody tested things properly, that diminishes the project leaders role in failing to organize testing.
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!
Code Complete is a great book that focuses on teaching software programmers how to manage software projects. It will do a good job of showing you what else you need besides code to finish a project.
Fewer bugs?
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 applications. I suggest starting to learn about the "agile" family of methodologies if you're working in a small team.
Good question, you're not alone in asking it. Change the question a little bit, rather than asking about yourself, generalize it. Most CS students complete assignments that way, so the question becomes 'how does ANY person learn to engineer effectively'. Certainly practice plays a large part, but quite frankly I think time is what really teaches this.
If learning to engineer didn't happen naturally then NOBODY would could do it. Every problem given to a CS student is going to require a platform and have a unique set of requirements, these details will guide most of the major decisions. You'll only need to architect 25% of the final solution and this is where most of the discussion and engineering will take place.
Also, as an entry level MS student, you'll never be given a task you can't complete at a normal company, even a start up. Trust me. Nothing to worry about, especially when entering a large company.
Sounds like you already did.
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.
Most states have a pretty clear cut path to becoming an engineer. Take an EIT test, work in a related field for some years then take a professional engineer exam.
Engineers know the box. They know everything about inside the box and are experts about the box. Hackers know the box; however, they look at how they can change the box.
http://www.mafiasecurity.com maf
A professional 'pool engineer' will analyze the table, formally state his intensions (3 ball off the rail into that corner pocket) and then execute it successfully. I am a 'pool hack'. I will the analyze the table looking for something a I can make, take aim and shoot hoping something goes in somewhere.
So I think the difference is two-fold: 1) the skill set to analyze/execute a successful solution to a problem and 2) the formality of planing, costing and documenting the solution.
Academic concentrate on the finding out where his solution works. Engineer mostly concerned with situations what to do if it doesn't.
Tell me how to hire engineers and what makes a good one... and the best interviewing strategies.
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.
Learn about Test Driven Development (TDD). You don't need a book on it, simply use Google and learn about its importance for software quality, and learn how to use JUnit. Adopting TDD will change your development process and the way you develop software. Your software will be more correct, more reliable, you'll have an automated suite for maintaining it and your software will be better designed and more modular (required to be more testable). Once you get the "testing religion" your view on good development style will change (and you'll see that a lot of the software development "orthodox" wisdom is actually counter-productive to testing and what really matters when developing reliable software quickly).
On the job training of course. Work for a company that does Engineering and Manufacturing... preferably something like Aerospace where they have dedicated software testing teams and rigorous design documents.
So you don't get confused with a real, actual engineer.
Take the FE (and the Canadian/European) Equivalent and tada. You can call yourself an engineer.
I was in a similar situation a few years ago. This was the most useful article I found,
http://drdobbs.com/architecture-and-design/217701907
But really don't worry that you are not a verse in SE. I would say the majority who program have just a small working knowledge. The smartest thing to do is when you get to your job is ask what their processes are and what they expect. Use the terminology, like agile, cmmi, unit test, process development, etc. If they have a process or model they are following, they will be thrilled your asking. If they don't then hope they are all master programmers and everyone works well together.
I have secretly hidden some mispelled words in this post. Can you find them?
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.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
Should of went to a tech school CS is not for real work skills. Even more so at the MA and up level.
How much real work did the classes cover?
You need to get some real work skills or at least do some open source work?
In the real work place you will see lot's of old code and other left over stuff that you will need to work with.
I hope that helps!
First, Coders are not engineers. There is no liability, or signing of code (in the way drawings and designs are signed).
Second, sadly, that is the real word.
Most software developement takes places in teams, which means you have to learn to deal with people and code written by others. That means having to deal with colleagues who use a different coding style than what you would prefer. Who use a different way of formating code, naming conventions that you are used to. You will have to resist the temptation to reformat all the code that you encounter. Also you will encounter strange code constructions that you think are wrong. And often they are also wrong, but they work (for the moment), and you have to learn to resist the temptation to start refactoring the code. Especially if you are working with a code manangement system, do not make any unneccessay changes to the code, because you are creating extra work for those who review your checking, because they have to spend extra time, and they don't like this. Also don't feel hesistated to make 'stupid' questions, and listen to the answers you get. Sometimes, you will be told that something is there for historical reasons, and that is often the only reason that it is there. And there will be colleagues that you will get around easier than others. Actually the whole messages burns down to: learning to adapt to the style of others and having the right attitude. Software enginering is often a group effort against an individual effort as you have been doing now. For the rest it is still 80% hacking the way you have been doing it.
Really folks, can we do away with this persistent lack of respect for logging style debugging. Most IDE debuggers suck if you need to look at more than the internal state of a single function. Yes, there are instances where debuggers are better (conditional breakpoints in a long running loop, for example), but I get far more info out of debug logging then tracing through a function in a debugger.
As for the OP, you have nothing to worry about. Those who lose their hacker mentality and approach everything from an academic standpoint are the ones with a problem.
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.
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.
Check your premises.
Engineers ENVISION, DESIGN and CREATE the box, which a hacker is dependent on. Engineers don't need hackers, hackers need engineers to do the hard work first.
"When you see a good move, look for a better one."
The most important thing I've learned over the years about being a software engineer is not to rush off and implement the first solution that pops into my head. Often, the hacker mentality is just to crank out a sufficient solution, so that you can pop your stack and get back to whatever it was you were trying to do in the first place. But as an engineer the best thing you can do in that situation is STOP and THINK. Don't let yourself write a line of code until you've had time to fall out of love with your original idea. If your first solution turns out to have been the best one, so be it; you've just wasted an hour. But it's far more likely that the improved solution you get as a result of the investment of that hour will pay your back 10- or 100-fold down the road.
Even if you're the only one developing, you'll want someone else to try it out, shake it and see if bugs fall out. Usually it's more than just you developing it, and other people testing, and other people managing. Getting along with others is the main thing involved with a professional's life as compared to the lone hacker mentality, I have found.
First off, a rant. Either your Computer Science program/dept does not truly deserve the name or you did not fully attempt to master the curriculum as it is intended. I know it sounds harsh, I am mostly annoyed by the constant misconceptions about CS that pop up here on /. from time to time.
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).
Don't worry. The field is not mature either.
One of the most eye-opening things I've read is On the cruelty of really teaching computer science by Edsger Dijkstra, one of the old computer science greats. While I don't agree with every point, it's well worth reading, and he has some choice words about software engineering:
"A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter 'How to program if you cannot.'"
and you mimic him/her. How do they act during meetings? How do they write tech-specs, documentation? Look at their check-ins, how do they approach code? How deep can they dive into a discussion? Then ask yourself how do you act during meetings, how does your writing stack up, how would you would have written that, where does your knowledge end? Repeat.
There is something to be said about faking it until you make it. Great engineers (and I've seen several in my day) have found a way to balance--their time, customer requirements, dealing with management, and other engineers and combined it with deep knowledge. Little of what separates a decent engineer and a great one is know-how, though. What really separates them IMHO is their countenance when dealing with a massive, ambiguous problem, their delivery record and the trust that they've garnered from that, their effective use of time and their innate, almost magically ability to be aware of any trade-offs the team and organization may be making due to their deep understanding.
If you aren't around good engineers you probably won't be one.
"Engineer": "Hacker" with enough scars.
We live, as we dream -- alone....
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 tech school staff, the person who develops a novel or efficient solution a problem quickly hacked together by someone who didn't really appreciate algorithm efficiency, that sort of thing. Being an IT guy is not CS. Being a professional scientist is about using a scientific process and knowledge kit to apply to a problem domain (computing in this case), so error and failure rates, efficient algorithm that sort of thing. Efficient algorithms and representations of data is a big area of CS since it sort of encompasses languages (is it easier or harder to efficiently implement an algorithm in a particular language, why?), the tradeoffs etc. You're an expert in what data is, and what you can do it, whereas a software engineer is an expert in how to use a computer to solve a problem with data. If you trained in one expect a period of retraining to do the other, they aren't mutually exclusive but the are separate and somewhat complimentary.
I teach both SE and CS students. Because there is a LOT of overlap, and you can learn in CS SE skills, but the emphasis on the typically individual responsibility of a scientist vs the collective responsibility of an engineering project aren't the same. If you get a job it's up to them to teach you the area you are deficient in, SE's are usually good at designing a system and hacking it together to work, CS is there to make it efficient or to figure out how to solve a novel problem even if they aren't the one implementing it, or figure out what problem is even solvable (whereas the SE is concerned with whether or not the solution is implementable).
I realize the US is casual with the use of language here. But if you're a scientist you're not an engineer. If you have an MA you aren't an engineer. If you have an MBA you aren't an engineer. You can become an engineer with training after the fact, but if you wanted to be an engineer you should have been an engineer.
I wouldn't consider 'open source' as work in the same way as real work is. Volunteering to help build a house uses a lot of skills like being paid to build a house. But the 'on time, on budget, with the co-workers we choose for you, not the ones we want, on the hours we tell you' is a a different environment. If you can get an MSc in comp sci you don't need to 'work' experience of open source particularly (nor would you necessarily want to give the impression you're willing to work for free).
And you see old code everywhere. Academia is full of it, because someone wrote code to solve a similar problem to this 10 years ago, and you're using it now and it's been 'maintained' by 5 other grad students who've all long since left, and you're stuck with it now. Industry is full of it 'because it works', and government is full of it because they can't get money to put in something new even if they want to, or they put money into a politicians pet project that had nothing to do with the requirements of the actual problem.
Engineering a house:
1. Gather requirements
2. Write a spec
2a. make a prototype because users can't vision the spec the way you can, try nailing planks together to understand problem better.
2b. Did they like it? No? Go back to 1.
3. Design house to new spec based on plank prototype feedback.
4. Build house to design
4a. Realize that you didn't fully capture the problem because this is designing something *new* after all, not a simple assembly of a standard house, more like designing a new type of house each time.
4b. Get feedback, fix problems short-term by nailing planks together.
4d. Go back to 1 for the next version, remember to take some planks with you, you'll need them, it's not a perfect world.
A hacker tackles problems because he wants to.
An engineer tackles problems because he's been told to.
Do you want to be someone who enjoys what he does, solves new problems by applying old solutions or variations thereof, then rewrites the manuals? Be a hacker.
Or do you want to be someone who spends his entire working life reading manuals and doing what he's told? Be an engineer.
Operation Guillotine is in effect.
The difference in between a hacker and an "engineer", for lack of a better word, is not "testing method", per se
The difference is that a hacker hack because it's something the hacker WANTS TO DO
The so-called "engineer" ? He or she does something because it puts food on the table
Nothing to do with testing method
Nothing to do with methodology what-so-ever
I've been in this field for ages and I never identify myself as an "engineer" simply because I don't need to do something out of the need of putting food on the table
Muchas Gracias, Señor Edward Snowden !
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.
To "code something up (using a lot of prints to debug)" means hacking, i.e. rigging software together with the emphasis of doing it as quickly as the intuition allows, at the expense of readability, reusability, reliability and ease of change.
Agile software development, in a nutshell, means acknowledging the fact that noone can really know what true final requirements for the eventual finished product are, so the idea is to start small and simple with a small feature set and gradually evolve into what the customer really wanted in the way of iterations - but at all times keeping the code tested, clean, readable, reusable and version controlled. It's about always having working version of the software, whose expected functionality can be demonstrated and verified with automatic tests, while using them to constantly refactor the code to better and clearer. It's about keeping the cost of changing the software low, while on the other hand, the cost of changing quickly hacked-together applications increases exponentially with complexity.
Income and paperwork.
After logging in slashdot still does not take you back to the page you were on. It's been that way for 20 years.
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 caffeine-fueled hacking.
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 middle of a project, or at the very least you'll have to deal with existing code that somehow affects whatever you'll be writing, code that grew with time, was patched, fixed and altered a hundred times and looks it. Meaning, it will be a mix of various coding styles, parts that nobody really knows anymore what they do or how they do it (because whoever wrote and maintained it is no longer with the company), with hardly documented features and even less documented side effects.
This is what you'll encounter in your job. In other words, the "hacker" approach is most likely exactly what will allow you to survive in there. It's the unfortunate reality that code is more often than not in a rather bad shape and few people are "true programmers". Hell, you have a CS degree? Congrats, chances are you're already miles closer to being a programmer than most people working there...
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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 painful in their current workflow? A possible answer is they can't do it.
Given these pain points. Create a list of pain points you can address. When you can say how these will be addressed, they become a functional specification. Part of the functional specification may include performance related concerns if it is driven by the persona.
Given a functional specification, you will need some architectural design to make the implementation possible, document that.
Now you have enough to say how you will test it; some will be unit tests and some will be operational. As you document the testing, you may find your functional specification needs to be more precise.
From there, use what you already know. Improve upon how you implement as time permits but keep the larger picture in mind.
Ideally you will have others review your documentation and code before letting it out the door.
When you are done, everything goes back to the original persona with pain points you are improving. If the tests are passing and the end user is not satisfied, you missed a requirement in your functional specification.
There are 3 dominating schools of testing, and then something in between.
The Microsoft way is to let users do the testing, it is considered the most cost effective. Throw out some early release versions, then it is peoples own fault when they lose data.
The Apple way is to let the CEO do the testing. This has the side effect of everybody down the food chain tries to make things work better than good enough.
Outsource the testing. This is difficult, as you will have to specify what cases to test for. In Denmark a company has great success in using people with autism / aspergers to do the repetitive testing tasks. They are way better than most other people you can get, who will get tired from testing after 5 repetitions if they have much brain.
So it would help to know what your new job is. Blue-sky research? Existing install base (aka maintenance)? New product development?
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!
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. The discipline allows me to build great things, not just toy projects, which is all that the undirected, undisciplined hacker will ever build.
Because I'm willing to learn (to read those manuals, and pay my dues), I've worked on everything from embedded to massive distributed systems.
Being an engineer and a hacker don't have to be mutually exclusive. Perhaps not all engineers have the drive and passion to be a hacker; perhaps not all hackers have what it takes to acquire the discipline of being an engineer. But those who can be both get to play with the biggest toys, get to work on the neatest problems, and, honestly, make the most money at the end of the day.
Check your premises.
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
Muchas Gracias, Señor Edward Snowden !
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 time on paperwork and moving buttons in a user interface.
assignment != equality != identity
Go with it, just like the guys that call themselves Architects, Gurus, Batman or whatever, just don't try to pretend like some of the others above that it makes you equivalent to a professional engineer.
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.
Your view of what a SW engineer does is sadly overly idealized. I've been at the profession for 20+ years and have at best only sporadically glimpsed the world you describe. I wish that there was more actual methodical engineering involved, but most projects very quickly jump to the "we just need to get sh*t done" mode. The skills you describe somewhat negatively as "hacking" would serve you quite well in many or maybe even most shops.
The mythical man month is definitely the one to look at.
The most important message: there is no silver bullet.
Why? because you cannot reduce the essential problem, you can only improve on the accidental.
Therefore, know how to design and manage the essence of your problem.
Don't start to think in technical terms, start with a business architecture (not only for development time, but maintenance),
then look into practical technological solutions, then code.
In a private sector organisation, commercial pressures will probably dictate working practices to some extent, and constantly changing requirements (of lack of requirements) are likely to be the biggest annoyance.
You will probably not get away with 'hacking' stuff, if your organisation has any level of competence. If you want to do this, go somewhere which is run be idiots, and staffed by idiots. There are plenty of such places.
Most organisations that develop software professionally will have code reviews, design meetings, and formal testing systems. As a junior developer, you will be expected to follow the processes that are in place, and as a result, should pick these things up, fairly quickly.
Big software projects require competent up-front architecting. I have worked on various pieces of software that were not designed properly, and they usually just become completely unmaintainable, and require re-writing (at least in parts). This is usually a good opportunity to modularise. The biggest skill is to learn how to manage the people who manage you, so that they don't impose decisions that compromise quality and design in the long run, and eventually make further development and maintenance impossible, leading to an outflux of all of the competent developers, and eventual death of the project, or complete re-write.
Architecting large pieces of software is very little about sketching individual algorithms, and much more about deciding how to fit all the pieces together in an extensible and maintainable way.
I'm still a "hacker" 25 years after getting my first computer, studying data processing and computer science, and writing and maintaining software. I never cared for the term "software engineer." Back when I started, "hacker" wasn't a bad word. A good "hack" meant a great prank, or a really cool or elegant solution to a difficult programming problem. It was also used by hardware folks, since most of us could take our computers apart and put them back together ourselves.
Professionally I have always used the word "programmer.". People in IT and management both respect the word, and you don't sound like you are trying to make yourself some titled position, like "sanitation engineer" instead of "garbage man."
Nitewing '98
Everything works...in theory.
Learn to test. Learn to manage projects. Those can be taught. Hacking can't, and if you've got that, you will eventually be the trifecta.
You go from engineer to hacker, not the other way around. Engineers are like hackers stuck inside the matrix
Believing something doesn't make it true. Not believing something doesn't make it false.
Lesson one: Don't pay any attention to the idiots who are incapable of moving beyond a strict definition of engineer.
CS teaches you how to build something that works correctly. CS doesn't have much to say when things don't work as expected.
If you can't debug, really, really well, then you can't be an engineer. That your own programs won't work right (and you can't fix them) is only part of it; Debugging causes you to learn what does or does not work in the real world, ivory tower CS solution be dammed. With that knowledge and understanding, you'll better engineer your next program taking that into account.
My
...not the use of the waterfall model.
This is *not* controversial! Look up the term "engineering" in a dictionary or Wikipedia if you don't believe me.
For some reason, a lot of people have the mindset that engineers have to do everything as per the waterfall model, and that software engineering is all about process, methodology and code maintainability. This sort of thinking is really just cargo cult engineering.
Other branches of engineering often do things in a waterfall-like process. For example, a bridge has to be designed before it can be constructed; you can't build a bridge incrementally, and construction takes a long time. But there's no such requirement for software. Software can be developed incrementally, and compilation is very quick compared to construction/manufacturing.
There are other engineering fields where things are engineered incrementally. As an example, take a look at how an F1 car evolves over a season. You'd have to be crazy to claim that the people who design F1 cars are not automotive engineers because they don't do waterfall.
What separates software engineers from hackers is that software engineers analyze the systems they work on, using computer science and mathematics. They reason about performance and computational complexity, they reason statistically about reliability and fault-tolerance, or they use mathematical models of real-time systems to schedule real-time tasks.
They don't spend all of their time writing documents and talking about maintainability.
Documentation, maintainability and process are all important things, but they're not the defining traits of an engineer. What makes an engineer an engineer is their application of science to solve a problem.
If you want to make the transition from a hacker to an engineer, learn the maths and computer science that underpins the software that you'll be working on. Not all software needs to be engineered; a lot of internal corporate web apps don't need to be engineered, but sites like Amazon, Facebook and Google do. A lot of real-time and embedded software needs to be developed by software engineers too. If you want to be a software engineer, make sure you go to work at an engineering firm.
Or don't. There's nothing wrong with being a hacker. Just make sure you don't become a cargo cult engineer.
get a clue fucktard
I find your understanding of the term 'hacker' somewhat ironic.
The historic origins of the term are in conflict between the alternate definitions of:
someone who attacks systems attempting to intrude or damage them, vs.
someone who authors carefully written, precise code that effectively and efficiently satisfies a need.
From your own description, I would term you an inexperienced "code slinger" - or someone who throws things against the wall hoping something will stick.
You're be best advised to consider what it will take, over the many years of your (future) career, to be considered a 'craftsman'.
From there, I think that your question transforms into: "What is craftsmanship in the context of software development?", and
"How does one develop into a craftsman?" - what skills, practices, and qualities are required?
First and foremost I find it is "attention to detail" - which is more an attitude than anything else. Passion also comes to mind.
Read things like "Good to Great" by Jim Collins; learn how to "be the job"; continually ask: "Is this that is needed?" and "Are the users happy?".
1. Understand the users and businesses who are going to use your product, and what they need from you to be successful. (And create a minimum no. of support requests later on). Spend actaul time doing it. No, really!
2. Understand that testing is needed to uncover all flaws in your program. Learn to appreciate the good testers, who do anything to break your code. Again, it will help minimize the shit storm, when you release (flawed) code to production.
3. *Then*, you can start honing your hacker skills, selecting the algorithm that will squeeze out the last 2% real world speed increase.
The most successful engineers I have met as a project mgr/product owner master the 3 above.
As an Electrical Engineer who went software, the one thing that must be noted is that the V model for development is great for electrical and electronic development where spinning prototypes is a lengthy process and then testing, redesign etc are lengthly loops. But companies that adopt this approach for software are crippling themselves.
Shorten the testing loop. Make your methods smaller and single purpose, and document them with doxygen style comments so you can generate out nice "detailed design" later from your souce. Work within any one of the *Unit Frameworks JUnit, CppUnit, NUnit, etc.
For gods sake use automated build an CI to perform full automatic regression testing.
There are a million and 1 free tools out there to help you be more efficient as a "Engineer" as opposed to a hacker. But really the only difference between a "Hacker" and an engineer is keeping documented evidence of your hacking and providing proof of testing.
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.
If you want to transition to being an engineer, you're going to have to go back to school for engineering.
Software "engineering" is programming. It's not engineering. You cannot be a licensed Professional Engineer in software.
Being a good hacker is fine, but acting like a cowboy (someone who is reckless or irresponsible) when putting code in to production isn't.
Creating quick and dirty solutions can give you great insights, implementing them that way in production environments will bite you in the ass later on.
A hacker gets things done. An engineer enumerates the pros and cons of various solutions and picks one.
The work you do will rarely be complicated or sexy, in the CS/theoretical sense. But it will be put up against a lot of non-technical forces like time, budget, politics, etc. Being an engineer is about navigating this imperfect space. A hacker will come up with one solution, but an engineer will come up with many.
You're multiplying the solution space by a certain amount of non-technical dimensions and accounting for the difference. That ability will come in time. You will find out that technical correctness isn't always the #1 priority.
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
That is exactly how we, "engineers", often do it.
How do you get out of the 'hacker' mindset?
You don't. The "hacker mindset" is precious. Never lose it. Illustration: not earlier than yesterday I presented a Proof of Concept to a client. The guys were thrilled. Basically, all I had done was hacking an IBM tool, to make it do something it does, out-of-the-box, badly. Don't change, dude !
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
Actually, university education is very detached from working in the real world. Most teachers want to make a researcher out of you, not an engineer.
After your graduation you need at least six months or a year of real life work to learn to put the education to real use. You should be happy that you alread are a talented hacker, so you can be productive from the start.
With the time you will recognize problems coming up in your day to day job, that you learned about in university.
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 customers.
As I said above, my opinion is to go with it, just don't expect everyone to take it any more seriously than "Guru" and don't get suprised when people occasionally look down on you for adopting a title they think you don't deserve. Most of the time that's their problem. It's my problem when somebody at an simple course certificate level and no experience uses it as a bluff and pretend some sort of ability they do not have. That pisses me off so much that I react every time the "why can't I call myself an engineer" question comes up even if somebody is a the point where they are effectively working as one anyway.
Anyway, IMHO it's a matter of convincing a professional body of people with that title that you deserve the title (eg. real Architects have to jump through a lot of hoops before they are recognised as such), otherwise it's as meaningless as calling yourself Emperor.
There are different ways to become an engineer. First, the hard way. You code somthing up and then you aren't able to maintain it sufficiently. In the end you have to rewrite. When you do that cycle often enough or have seen rotten code of others often enough, then you should normally be able to make the transition. The first thing you can focus on at that point are methods and procedures. All that shit that hackers call a limit to their freedom. Today agile approaches are very popular, but they require a lot of discipline and they are merely improved old methods. The old method to learn is V-model or RUP or even the old "requirements -> design -> detailed design -> code"-method. For agile methods you have to learn that you have to iterate these processes and that you always start with a requirement cutting it into pieces called features and then add something to you design.
Second, you could have it easy and start reading and implementing engineering methods in your job. In this version you just believe that it hurts not to do so, which leads normally to less motivation.
But the main lesson is, learn and use the methods of software engineering. With time you will learn to use them wisely. And yes you should have heard software engineering classes in grad school, but you can still learn all that stuff. The big picture is not too complicated. Complicated things arise on the road.
That's the difference. A hacker and and an engineer can both write most programs.
An engineer can prove it is stable, reliable, maintainable, refactorable, and transferable to other programmers.
Getting there is what separates new programmers from old ones and hackers from engineers.
For some reason, a lot of people have the mindset that engineers have to do everything as per the waterfall model, and that software engineering is all about process, methodology and code maintainability.
I think this is because the traditional methodology (or should I say Methodology) cult has branded itself that way for a very long time. I had a CS course on software engineering with a 800+ page "software engineering" book full of intricate ways of producing tonnes of almost completely useless documents and very little real-world advice on how to actually design and develop software and manage a software project.
What separates software engineers from hackers is that software engineers analyze the systems they work on, using computer science and mathematics.
And thinking critically about new ideas and their application. There are lots of fads and architecture astronauts in software development.
That's correct. "Programmer" is the right designation. An engineer creates a technical solution to a physical problem which will work without failure after deployment. A programmer creates a logical solution to an information problem which due to complexity will have errors, and is therefore an ongoing job, like a service. And no, machine maintenance IS NOT comparable to bug fixing; a machine with a bug does not work and has to be recalled.
going from housewife blogger to journalist?
It is good to see this discussion. Long ago (in my early career) I asked the developers gathered for our particular task these question: what is a software engineer? How is an engineer different than a programmer? Nobody had an answer that I liked. So start with basics: what is the diff between engineer and construction worker? In construction engineering, an engineer designs a thing to do more than fit its purpose, but the design has to be "safe". Safety is the primary goal of the engineer. An engineer builds safe bridges, buildings and the like. And so it is with software. An engineer builds safe software. Software Engineers can hack prototypes together, and obviously do programming to implement a design, but they ensure the design is both testable well tested. Software Engineers love the opportunity to have other developers review their designs and their code, because it helps find defects.
Write it, fix it, learn what you did wrong, lather, rinse, repeat. It's how ALL of us gain proficiency.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
I'm not sure if masters level is any different but the undergraduate program I was in there was only a 2 elective difference between CS and SE. I took all the electives for fun. When I graduated they asked did I want to have CS or SE on my degree. I said why not both. They said I only paid for one degree. I still don't remember which one I am.
I love Jesus, except for his foreign policy.
I work in the embedded field (+10 years), and while most of my work has been with C, switching to OOA, OOD, (C++) has been a huge eye opener. I had been using TDD in C, but there was much much more to learn.
I consider myself to be still on the learning path, but I believe I've advanced a great deal with the following:
1. You need a good metor (I've seen others mention the same)
2. The following books helped me:
- Code Complete 2
- Clean code (IMO these complement each other)
3. Have a look at these online resources:
- object mentor (I found the craftsman articles both entertaining and informative).
- Some design patterns
Good luck
Those are two major factors I haven't seen while skimming comments.
Most of your communication is done through keeping in touch with your peers. Talk to them, understand what they're doing, etc. But also long term, document your code as you go, either with written documentation or, better, with tests. Especially, learn what they're doing right, and tell them; people need recognition from their peers.
Professionalism is pretty easy: learn how to use version control and continuous integration, e.g. Jenkins. Use CI, especially, to make sure that you fix your bugs right away. If you set it up and use it rigorously, you'll find you can put out some very high quality code, even though it will be at a slower pace than you're used to. But for large projects, fixing bugs "later" is madness.
the really productive and happy software engineer is the one who can hack something together, or be meticulous and pedantic, when the job calls for it. the key is knowing which approach is the best route for the project. there can be elegance, simplicity and organization in both.
Join the Slashcott! Feb 10 thru Feb 17!
- Be organized
- Document, Document, Document
- Write code assuming it will have to be changed in the future
- Write code assuming someone else will maintain it
- Write code assuming anyone anywhere with any level of skill will consume it
Your best bet for preparing is to get involved in a good open source project. Find one that interests you, but make sure it has a well organized ticketing system (using Trac or something similar) and good peer code review. The right project will quickly break you of bad habits.
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
All the other things, like whether to use a revision control system, an IDE, particular technology etc. are constraints provided by your environment or chosen based on intermediate results of your "research".
"I love my job, but I hate talking to people like you" (Freddie Mercury)
You just described yourself as a boy who makes dirty hacks, not an hacker in its (obvious) positive meaning. You'd hurry to become an engineer, then, at least you will upgrade your poor status. Then, if you're a good one and will keep hard studying/practicing/working, you may become the hacker you say.
Turn on New Yankee Workshop and watch Norm. He doesn't bang together a dresser, table, chair, or hutch. He carefully analyzes the inspiration for a piece, designs his piece with modifications (often including changes that make the piece easier to produce or more durable), and spends a good deal of time crafting jigs and other infrastructure that help him construct the piece. Part of the secret is that he crafts the jigs and other helper bits with as much care as he crafts the actual working piece.
Translate that to code. Start with a firm set of requirements and a design for what you want to build. Check it out from all angles. Then construct your infrastructure -- build environment, test environment, tests (if you don't spend at least as much time thinking about your tests as about your deliverable, you may want to reconsider what you are doing), etc. THEN construct your deliverable. Take pride in your work. When you cut corners, know exactly what the cost will be and what the benefit will be, so that you know why and when to do it (or not do it) again (Norm doesn't pay as much attention to the finish on the underside of a table as he does to the top).
To employ an unfair generalization, hackers concentrate on The Thing, while engineers concentrate on the process of making The Thing. A hacker improves code, and an engineer improves the coding process. A hacker thrives on making every experience a new adventure, starting with a clean slate. An engineer thrives on relating every experience to past experiences, trying to leverage knowledge and infrastructure (it doesn't always work, and it can be confining, but it provides a methodology for deciding when to wipe the slate clean).
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
Loading...
1. build a bridge
2. have it not collapse
3. congratulations, you're now an engineer
A hacker does it for fun
An engineer gets paid to do it for fun
The computer industry is mostly experiance driven, so my first question is; what did that "masters in Computer Science " get you that you id not have before, other than a piece of paper?
- Get used to being assigned to projects at the finish milestone - no money - so sorry
- the customer wants something invisible before we get paid - please hurry
- Get used to: no time, no documentation, no drawings, take look - got to run - don't touch anything - it's live
Maybe you lose work because you're a raving, barely-interesting nutcase with poor language skills. Just a thought.
In some juristictions (eg. Ontario, Canada) the Professional Engineer's association takes you to court and collects a large fine from you if you call yourself an engineer and don't have a license from them: http://www.peo.on.ca/enforcement/callmeengineer.htm
So to "transition from hacker to engineer" with a Master's in Computer Science, you'd turn around, go back into university, and enroll in an undergrad Engineering course. The last time I looked (admittedly over a decade ago) the closest was "Computer Engineer" which did some software, but had rather more in common with Electrical Engineering than Computer Science.
Be aware of the legal status of the word "Engineer" in your juristiction before you add it to your title.
CS degrees will never be engineering degrees because too many CS people keep saying math is not important I know how to code already.
Because I'd like to recruit people from wherever you learned. The recognition that testing is appropriate, and that you have things to learn, is so rare among working systems personnel that your school and mentors should be congratulated.
If you can, talk to the QA people where you work about their processes. Don't simply take their word: have lunch with them, walk through it with them, and note where they deviate from the planned or published release process and why they skip or redo parts. (This is often political, which I'm afraid is part of testing.) And get involved in some GPL projects with test suites, to learn more about how they're structured.
If you want to be a Software Engineer??? There's little in common - a Computer Engineering degree would be more appropriate, and if you had "Electrical" in that degree title you'd have an even stronger engineering basis.
The first level of programming is hacker. Most of us started there. Basically you are screwing around and after a while your screwing around gets better and better until someone pays you. This is programming as art but this is still fingerpainting. People can get really really good screwing around but there is a limit. Often a master of level 1 might know PHP inside and out. The next level is where you are properly educated. Not necessarily a degree but you need to learn the core, assembly, some discrete math, etc. At this level you can start doing things like building VMs, your own compiler, use OpenGL, etc. Many people graduate from a university thinking they are already level 2 but even their fingerpainting sucks. Many people mistake UML, SCRUM, and other faddish things as level 2; wrong. Hard core math is a key piece in level 2. .... programming is much more than programming. It is project management, communications, database admin, server admin, graphic design, psychology, plus much more non coding stuff. One of the few certifications that will get you way ahead in programming, oddly enough, would be from the PMI (Project Management Institute).
Level 3 looks a huge amount like level 1 as you often go back to fingerpainting. The difference is that there is less time wasted screwing around. It is like one of those artists who walks up to the canvas and with 3 strokes give you Jimmy Hendrix.
So if you want to move past hacker the next thing to learn is real computer science.
But
How do you get a CS "Master" without learning to use a debugger?
Once you really learn to use one, you will love and will not understand WHY you haven't using it before. I always assume that if you do CS on your first semester you learn to use a debugger. Why haven't you?
Here are some suggestions to becoming a proficient software engineer:
1. Learn to work your way up the capability maturity model (and help your company to do so). See item 6 in the following article.
Learn to avoid the "7 Habits of Highly Dysfunctional Developers". http://www.ganssle.com/articles/7habits.htm
2. Jack Ganssle's articles are great reading for programmers wanting to build reliable systems. They are helpful for both embedded programmers and people working on other platforms.
http://www.ganssle.com/articles.htm
3. Here is Jack's recommended reading list.
http://www.ganssle.com/bkreviews.htm
I have found his own books to be useful.
http://www.ganssle.com/book.htm
4. Jack's articles in Embedded Systems Programming magazine contain lots of programming wisdom.
http://www.eetimes.com/electronics-blogs/21/Break-Points?Ecosystem=embedded
go study engineering.
i've had a guts full of scientists, technicians, and other tradesmen calling themselves engineers. you may have read the art of motorcycle maintenance, but sir you are no engineer.
two words: critical thinking--you don't develop that in CS.
Read Code Complete. Then practice the principles outlined in it everyday on every project, and you will no longer be a hacker.
DBC is only about 8 years old and I'd wager that only 1-2% of programmers know what it is and how it works.Google DBC or Design By Contract and try it out on your own time. DBC works extremely well hand in hand with Test Driven Design, in fact I think it enhances TDD by making your software inherently testable and more modular.
The basic premise of DBC is that every class you create should have a contract and so should any publicly declared methods of that class. Violating the contract IMMEDIATELY terminates your program, meaning that errors get trapped at the root cause of the problem. This is entirely contrary to 'soft fail' and 'defensive programming'. Because DBC forces you to formally declare a contract for each class you create, it forces you to create understandable code--if you can't define the contract for a class, then you need to decompose the class into a series of classes that you CAN define contracts for.
"How do you get out of the 'hacker' mindset?"
I say don't change the mindset it is the best "one-ups" that you can have above your peers. It makes you approach problems differently. I used to be going down the bad cracker path in networking when I first started and then ran into some issues with my old ISP, I was curious about stuff and they sort of saw that so didn't push things further ... Then went to uni with the same curious mentality ... absolutely hated and couldn't stand attending lectures as it bored me to death, so took that as "me" time and didn't attend.. instead took a self study approach and aced all my units with HDs. Then networking certifications and now work as a network engineer. I found that the "hacker" mindset if you will is what is needed to turn you into a true engineer into whatever field you choose, it forces you to automatically think of the most elegant design to solve a problem rather than just coming up with something because "this is what I was taught to do it".
If you keep that mindset you will shine in the long run as the quality of your work will show through and in my experience it really does pay to be a bit quirky and different in an engineering role :-)
It's a difficult transition, and one I had to make myself within the last year. There are really two major things that helped me to become a much better programmer, and got me out of the 'hack/patch' mindset. 1) My company has a mentoring relationship set up - I had the good fortune of working with a mentor that had the right mindset, and worked hard at it. Even if your company does not have such an opportunity, try to find someone at the company whose work is well respected, and see what you can learn from them (or failing at that, from their code itself, since there should be plenty of documented changes). 2) Take your time. There is always going to be multiple solutions to any given problem. What will set you apart is if you look at it, and cure the problem rather than the symptoms. When you see a bug report, don't take it at face value. Find out *why* the software is doing the sort of thing it's doing, and fix the right problem. The hardest part of it is actually finding the right problem. The easiest analogy is thinking of yourself as a doctor. If a patient has a bad cough, a bad doctor will give you some cough syrup and call it a day. A good doctor will find out why you have a bad cough - sometimes the solution is a cough syrup, sometimes it's a chest x-ray and chemo. But the doctor that gave you cough syrup, even if it did end up being nothing more than just a cough, really didn't do his homework, and is going to do plenty of harm in his career.
Guess what? With 30+ years of programming under my belt, that is exactly what my career entails.
"Software Engineering" is a misnomer. While there are certainly aspects of programming which can be canned and automated, the creation of GUIs, reports, understanding requirements, and coming up with the right algorithms to IMPLEMENT those requirements is more art than science.
Engineering presumes that there are canned rules and "how to" guides to guarantee a program's reliability or a building's safety. There are no such guarantees with software, no matter how thoroughly you test a system. The only exception are "mathematically correct" theoretical languages that no one actually uses for production systems.
Keep doing what you're doing. Getting an engineering-focused degree will NOT help you find employment.
Good luck with your career -- I think you're off to a great start with your approach to coding techniques.
I do not fail; I succeed at finding out what does not work.
Books
Peopleware by DeMarco and Lister (and any of their other books)
Capers Jones' latest book.
Gerald Weinberg's books.
The Inmates Are Running The Asylum by Alan Cooper (UI design)
Software Engineering Economics by Barry Boehm (somewhat redundant with Capers Jones, but still a good read)
Technology
Keep current with latest trends to stay employable. Unfortunately, not many companies hire software engineers; they hire technology experience.
If you get tired of laboring at the 3GL "abstraction level" (Capers Jones' data will reveal the need for quotes), you should look at Executable UML as described in the like named book by Stephen Mellor and Marc Balcer. Other authors in this field are Leon Starr and H.S. Lahman (Model-Based Development), and another book by Chris Raistrick, Paul Francis, John Wright, Colin Carter and Ian Wilkie.
It sounds like you're more interested interested in the Quality Assurance aspects of the industry than programming. You can be one or the other, but not both, at least not on the same project.
It is normal for QA to be handled separately from programming so that the testing process can cover cases the programmers didn't allow for. It's an entirely separate discipline of the software process, and you are correct, there are standards and rules if you choose QA as a career path.
Just be aware that it takes a special mindset to enjoy QA work -- most programmers hate it because a lot of it is checklist regression testing and running automated test scripts, and programmers usually prefer a more creative career path.
Even without a career in QA, I strongly recommend that you read up on Six Sigma and ISO9000 to understand what the goals of those approaches are. Software creation and testing are a process, and both of those approaches rely heavily on documenting and improving the process over time to reduce the bug reports and improve the quality of delivered code.
I do not fail; I succeed at finding out what does not work.
I work in operations currently and have practiced development in years past. I think one of the keys is that engineers measure. I'm not talking about merely timing printouts, but really digging into the most effective use of CPU, Memory, Disk, Network. One other key is that whatever you create can and will most likely be in use for many years and it must be well documented, serviceable, and operations friendly. I've never encountered a black box that never breaks...and when it does it's expensive to re-learn what the code is doing and the intent. More often than not it just gets thrown out and rebuilt.
That's still better than what I'm seeing around me.
You get no respect from management or marketing and your career lasts only ten years! Seriously, I've seen jobs advertised as "mid-career", when the experience requirement was two years!
Reading the recommended books you'll see in other posts is a good idea. It gives you an idea what techniques might be necessary for managing a large, long-term system, that other hackers have figured out and described in corporate-speak. It also gives you the ability to speak to others in corporate-developer-speak. You'll find that *some* professional software development techniques are pragmatic at a certain team/project scale, and many are not. Follow your hacker instinct, and keep being a hacker.
Really, 95% of the software development employees out there are just using these rigorous methodologies to try to emulate hacker-ness, because they can't otherwise muster it naturally.
As a self taught programmer who's now doing it for a living I've run up against this problem myself.
I found this UNSW lecture series helpful:
http://www.youtube.com/user/unswelearning#g/c/6B940F08B9773B9F
as well as this one:
http://www.youtube.com/user/unswelearning#g/c/E621E25B3BF8B9D1
They are intended for beginners so you probably won't learn any new programming but I like how he puts an emphasis on clarity above all, something I may not have made such at effort at before.
There's nothing wrong with being a hacker, sometimes problems can only be solved using hacking approaches, sometimes you run up against bugs in compiled libraries which you need to work around using hackery techniques. But the flaw in the hacker is that the code is often only readable to that hacker, and even then only while that hacker is currently thinking about it.
A software engineer programs with the goal in mind of just achieving an effective and workable solution to a problem, usually under the structured guidance from management above him. A computer scientist who's also a programmer not only does the same thing but with the added goals in mind of making his code the most efficient running code possible on the target platform while understanding why a particular collection of code is the most efficient it can be upon the target platform. Software engineers are much less concerned about the esoteric stuff like efficiencies, and the "whys". They just want to crank out code thatr simply works and "Gets 'er done".
Don't change a thing my friend. Code your own code, but keep an open mind to things that will make you better. If a company chooses not to hire you based on your static skill set rather than your potential then you don't want to work there anyway.
My favorite Software Engineering methodologies are Scrum and Personal Software Process/Team Software Process.
Scrum is enough process to provide schedule sanity.
When management is concerned enough enough about quality to support PSP/TSP I use that.
Of course, not many companies care about quality enough to support PSP/TSP. It does require a bit of investment to get going with it.
In this forum you'll probably hear nothing but outrageous untruths about it (people will claim it's waterfall, not agile, etc) but people who actually use it know better. But you do have to be prepared for higher than usual staff turnover because there are plenty of people who can't deal with it.
Ironically there are a few Mexican companies that have embraced it and have low enough defect densities to be comfortable offering lifetime warranties on their software. Does that interfere with any of your biases and preconceptions? (About both software quality and Mexicans?) :)
And it was used by the creators of the Guitar Hero franchise.
But I'd like to second earlier comments that the most important part of being an engineer rather than merely a hacker is leaving your ego at the door. Hacker and software engineer aren't mutually exclusive, but neither are they the same. Mentor people, find good mentors, ignore religious debates and follow the data instead. Methodologies are just part of the toolbox.
Get input from others on your code. Have opportunities to review and comment on theirs. Both will grow your skills quickly.
Engineering is all about process. To transition from hacker/cs-grad to software engineer, you need rigorous developmental processes that guide how you specify (requirements), design (modeling), write (coding practices), build (turning code into runable programs), test (unit and system), document (in-line, reference, and user), and preserve (version control and release management) your work. Until you have internalized and utilize such processes, you will remain a "hacker", not an engineer.
Sometimes, real fast is almost as good as real-time.
...smart
Bukowski said it. I believe it. That settles it.
I would recommend the article "Twenty Dirty Tricks to Train Software Engineers", from Ray Dawson
Leverage what you know by choosing a company that that uses an agile method: it's not "mechanical engineering", but it's definitely engineering.
--dave
davecb@spamcop.net
To transition from hacker to engineer, let them operate away 60% of your brain.
If you can't afford this, _simulate_ having had the operation.
And I am serious. Engineering means controllable and reproducible results. If you code at the limits of your capacity, you won't be able to find your way through the code 10 years on, and if you can't find your way, how would anybody else?
Engineering as opposed to hacking is all about being boring. And not because of the dress code, but because of the code dressing.
Engineer is a professional designation in most jurisdictions - it requires a degree in engineering or equivalent qualifying exams as well as membership in the professional regulatory body. It would be illegal to represent yourself as such and you can face fines for even using that term in your commercial representation.
Now, I know this isn't exactly the meaning of your question. But engineering involves a broader exposure to technology in a number of fields to produce a holistic design. Computer science is a more specialized area of knowledge dealing with just one technology: coding of software. In my experience, this contrast sums up the shortcomings of computer science majors I have hired in the past. And I think that is the answer to your question, if you think about it.
There are hundreds of examples where Dilbert mirrors what has happened in my career. You can learn a lot from Dilbert, in both what can and will happen, and get a head-start on thinking of how you would really handle the issue.
http://www.dilbert.com/
Start hanging out with Electrical Engineers. Know thy hardware. Start building your toolbox (you probably have a pretty good start).
The only difference between scientists and engineers is that scientists deliver knowledge, engineers deliver tangible goods.
the obvious thing to do is read all the books people are suggesting -- it should be the non-obvious that you are interested in. learn the product life cycle from end-t-end and I'm not talking Agile here. Learn how the executive/business team goes about creating roadmaps and strategies, learn about how product marketing goes about their works -- do this for each organization -- then go and learn about how the product is moved into the channel and how the field organization is working with partners OEMs VARs -- learn how your target customer base uses and deploys the product and how their uses use it
when you finish this in 12-18 months -- you are prepared to be an excellent architect. many architects don't have a clue to this stuff -- so they architect products that are hard to develop, build, test, install, deploy, sell, partner with other entities. you'll have the info you need to architect not just technology (this is what 90% of the architects do), but to architect the end-to-end -- out to the end consumer and back again. you'll probably be standing head and shoulders above the status-quo you'll find yourself in an executive position before you know it
or perhaps you'll go and start your own business.
A computer scientist who's also a programmer not only does the same thing but with the added goals in mind of making his code the most efficient running code possible on the target platform while understanding why a particular collection of code is the most efficient it can be upon the target platform.
Which is EXACTLY why software development programs tend to be massively over budget and often don't work properly at the end of the day. Like who gives a rats ass if the matrix multiply is the most efficient it can possibly be if the overall system still meets the requirements with an inefficient matrix multiply?? You people spend so much time optimizing the academic worthless shit that there is no time left to actually finish the project, and then you blame management for unrealistic deadlines. Just get it working, make sure the code is clean and easy to understand, and move on to the next task!
Tesla was a genius. Edison however was a overrated hack who liked to torture puppies.
There is planning, debugging, managing, maintaining, documenting, and selling it. Fresh-face kollege newbies think the percentage is the other way around. If you are lucky your company will offload some of these tasks to specialists, allowing you up to half your time coding.
My current company is conglomerate of about 40 startups around a special vertical theme (energy). The startup phase is a lot about writing code. Its only a minority activity here. But then I dont have to travel to Abu Dhabi to sell or manage my code then, which is often the beyond the capability of a startup.
Start using a source code control system(git) even for personal stuff. Consider setting up a continuous integration system as well (Jenkins). Start coding things for personal use, but pay attention to their structure and break them into modules/projects for git/Jenkins. Code for yourself examples of how to implement some kinds of problems which you think will come in handy personally/professionally - how to ORM abstract a database, how to set up the structure of a webapp, whatever you think will come in handy. This becomes your own personal toolkit of "technologies" you can use for projects as they come up - grow it forever and replace bits as they go obsolete.
The dirty little secret nobody admits to is that what you described as 'hacking' is software engineering in the real world. Software development is a black art which all the methodologies in the world will never reduce to a simple recipe guaranteed to produce better code.
The only difference between software 'hacking' and software 'engineering' is the amount of testing.
and be nice with co-workers :-)
that's it!
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.
putting the 'B' in LGBTQ+
I personally know of two people with masters degrees in CS granted from a respected State University that know squat about programming, let alone the process of engineering.
I'd be better off hiring a high school drop out to help me program.
In my experience, people who didn't get an undergraduate degree in Computer Science/Engineering, and don't have an underlying interest in software, but got Masters Degrees in Computer Science, have all turned out to be the most incompetent Software Engineers I've ever worked with, because
a) they have no underlying knowledge of how programs actually work
b) they think they are experts just because they have a "MS in CS"
No it's research and development.
putting the 'B' in LGBTQ+
Read the Book of Five Rings. It applies to Engineering, carpentry and swordsmanship, and pretty much any other job. First you must practice.
> how do you make the transition from hacker (in the positive sense) to a real engineer?
I like your question. Start in a software engineering position,
try to do your best while still respecting yourself;
_engage the people around you_, find the people you resonate with.
Look calmly at your mistakes and at different perceptions and points of view, try to learn from them.
Try to keep a high spirit and a playful attitude.
Do not bash other people even when you feel you are right, learn to negotiate.
Sometimes it is better to at least discuss a non-optimal but still good solution,
rather than trying to force what you perceive as the optimal path, at the cost of burning all bridges around you.
Work relationships and the work environment need to be taken into account.
At the same time, reality cannot be ignored.
I would tell these things to the myself of some years ago. Whether that would help, I don't know.. we probably need to learn from personal experience in the end anyway. But maybe some road signs along the way pointing into some general direction can help at least a little bit.
Good luck, good journey.
If only everything was being over-optimized! If only!
First, I strive for elegance, not cleverness. Nine months from now, at 16:15 on Friday, or 02:00 any day, answering a call, I do *not* want to spend the next few hours figuring how I, or the person before me, had been "clever"; I want to easily understand what's happening, so I can get to why it's happening, and then how to fix it, in time to let me leave on time, or go back to sleep that night. A side effect of this is a) you can enhance it a *LOT* more easily, thus making your manager see you as a miracle worker, which might affect your next raise.
In school, you do minimal checking. DON'T EVER ASSUME that "this data can't possibly get here, leaving your error handling to fall through to a completely inaccurate error. Check *all* your input for reasonableness - don't trust the function (sorry, "method") above, and handle it correctly.
Finally, if you do something more than once, it's a separate function/method - don't cut and paste. And each of those function/methods should be short, and do *ONE* thing well. We used to say that if the function was more than a screen or two - 25 - 50 lines, unless it was moving a ton of fields, it was doing too much, and should have been decomposed.
mark
A big one is that clarity and maintainability in the source are more important than cleverness. That's not to say it should resemble Cobol or anything, but it is necessary to keep in mind that one day years later, someone who has never worked on the code before will need to make a change somewhere and won't have time or desire to appreciate clever obscurities.
Go download some open source program you haven't looked at before. Pick any little change that might be useful or at least could make sense and try to get it done as quickly as you can. Do that a few times and you'll have a feel for what I'm talking about here.
I'm not sure of where you plan to work, but in the United States the path is straight forward:
1. Obtain a suitable degree from a properly accredited institution. (This would most likely be an engineering degree, but check the laws of the state you wish to work in.)
2. Sit for and pass a fundamentals of engineering exam. At this point you are an Engineer In Training.
3. Spend 5 years working under the guidance of a licensed Professional Engineer.
4. Sit for, and pass, the professional engineering exam in the state(s) where you wish to practice. Presto! You are now a Professional Engineer (PE)
You need to be a PE to offer your services to the public as an Engineer. Most states require you to be a PE if you even include the word 'engineer' or 'engineering' in your company name. There are however numerous exceptions. For instance you can provide engineering services to industry without being a PE. Any company can give any of their employees a title with the word 'engineer' in it. Only a very few jobs require you to be a PE. For example the design of bridges and non-industrial buildings require a PE or Architect, the design of an airliner doesn't (go figure). In my state there is an exemption for the design of homes with fewer than 4 floors. Anybody can design a house, right?
My questions for you are:
1. What's wrong with being a Computer Scientist?
2. If you wanted to be an Engineer, why didn't you get an engineering degree?
3. Why sweat it. Just do what most people with physics degrees do. Just call yourself an engineer.
in canada - you are not an engineer, unless you've been professionally credited as an engineer.
what you are is a professional software programmer — to call yourself an engineer when
you are not is akin to adding a: PhD after your name when you never actually received those honours.
so stop abusing the term.
(i'm an amateur coder myself, but i strive for excellence in what i do)
best regards from toronto island
j
Isaak Newton put it well —
A vulgar mechanick can practice what he has been taught or seen done,
but if he is in error, he knows not how to find it out and correct it;...
Whereas he that is able to reason nimbly and judiciously about figure,
force, and motion, is never at rest till he gets over every rub.
(Isaak Newton, in a letter to Nathaniel Hawes)
that about covers it.
2cents from toronto island
jp
I cannot say it better than Rands himself: "In Software Engineering, the Process is the Product"
Read Rands in Repose.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
The problem comes down to you get a developer who believes the beauty of the code is the only thing worth looking at. He then gets assigned to add some features to existing code, looks at *other* parts of the code that don't need to be changed, are completed and are fully tested, reacts with horror saying 'what idiot wrote this piece of crap?!?' and then proceeds to spend a month rewriting it, breaking multiple other things in the process cause he doesn't understand the code. THATS the problem and it happens ALL the time.
Tesla was a genius. Edison however was a overrated hack who liked to torture puppies.
Your employer will clue you in on what he expects. Read your job description.
You mean like all the times when there have been exploits to *nix software that happen everywhere except some *BSD version that already saw the sloppy code and cleaned it up in their port?
Haha, well said!! Got a developer that works for me who is always late on every project he is involved. So one day I sat down with him trying to understand why he was always late. Was quiet an eye opener when I realized he was effectively rewriting the code 3 or 4 times per module.
He said he wasn't done until the system was perfect. Now I am all for optimized code but number 1 priority is a working complete solution and then it can be re-factored to improve efficiency/re-writeablity/etc.
No I'm not talking about sloppy bad code with bugs that allow exploits. I'm talking functioning *working* code that's been *tested* to be correct, but don't happen to match the aesthetics standards, or 'wow that's a cool way of doing it' standard of a developer that thinks hes top shit. Problems have to be fixed, but changing code to make it more elegant or efficient when there is no performance reason to, or making it run in 3 lines of convoluted code instead of 10 or 20 of very clear easy to understand code is just moronic.
Tesla was a genius. Edison however was a overrated hack who liked to torture puppies.
Completely agree. The first run through is to get it working with simple, very easy to understand code. Absolutely nothing fancy. Once it works, THEN you check the performance and optimize only those modules that need it. Simple code is far more likely to be bug free than come convoluted pile of packed code that no one but the writer understands. For some reason coders take pride in the fact that they can write code that works but no one else can read (even though the simple version would have taken an hour and they took a week). Baffling.
Tesla was a genius. Edison however was a overrated hack who liked to torture puppies.
Have you used the truss/tusc/strace to augment your logging? Here is a tool you can apply to an already running process that you do not source code for, and see all system interactions.
Good structure prevents bugs, good error checking keeps the bugs from being mysterious and good logging gets you in sync with your code when there is a problem. Good code has a lot of if statements, as almost every call can signal an error with a return or side effect.
Format your code for future readability, as if for a good text. Formatting prevents a lot of low level errors. You deserve well formatted code, and so do any future maintainers.
Write your apps modularly, for easy testing.
Start over from scratch if you realize the structure needs to change. Old strategies become bugs in new ones.
If you think you're "missing something" regarding software engineering, have a look at the SWEBOK, published by computer.org. It's a bit out of date, as it's lacking in security and quality sections, but it does have a compendium of knowledge.
As far as the actual practice of software engineering at a large company goes, my list looks like this:
1. Testing, and particularly developer-driven testing using automated unit tests. Why are you writing code if you can't prove it works? More importantly, why would your boss pay you to write code that you can't prove works? Really, if you learn nothing but Test Driven Development, you'll already be ahead of 50% of the people who call themselves programmers (including 50% of the commenters above spouting nonsense like "just keep doing what you do".) Of course, once you truly get it you'll realize that it touches all the disciplines of software engineering and design, and that a well-written test serves as your best documentation. And don't forget usability testing.
2. Design patterns. Civil engineers understand materials and shapes, and use tested and measurable components to accomplish tasks. A civil engineer doesn't need to reinvent the I-beam to build a bridge, they know the I-beam pattern exists and that that if they use them, they obtain performance of X, but have requirements of Y, and side effects of Z. Similarly, a software engineer should understand patterns serve a somewhat similar function in our domain. Pub/Sub will act this way, and it scales this way, but doesn't address retries. Note that patterns are abstract concepts, which makes them distinct from libraries or frameworks. I trust a pattern, because it's mathematically understood to behave a certain way. I don't have the same implicit trust of libraries and frameworks, because those are code implementations that may or may not be 100% correct.
3. Design principles. I like the SOLID principles myself, as I think they're exceptionally clear.
4. Security. Understanding concepts like default deny vs default allow, input validation via whitelisting or blacklisting, sanitized outputs, etc., are crucial in the modern world. Check out OWASP and SANS for long, long lists of reasons why security matters to software engineers.
As an engineer, it turns out there's an awful lot you have to do that isn't directly programming, but is still important, either to you, to your software, or to your company. So the list keeps going.
5. Estimating. If you end up at a shop that isn't at least Agile (I am, and I wouldn't recommend it) you'll have to provide estimates. Experience is the primary teacher here, but you may find modeling tools like COCOMO II to be valuable.
6. Code reviews. Understand how to hold an effective peer review, one that helps improve software quality without making the coder feel like an idiot, or afraid for his next review score.
7. Methodologies, processes, metrics, regulations, standards, and governance. Waterfall, iterative, RUP, Agile, emergent design, test-driven, behavior-driven, lean, all are processes for writing software. Processes also cover things like source code management practices, defect tracking and fixing, project management, etc. At one level metrics are useless things managers want to see regarding productivity, but as an engineer you can use them to help understand code written by others. Standards and governance likewise exist primarily to make the people signing the checks feel like you're doing something for them. They may not matter in a one-man shop, but when you're in a big organization, leading teams of developers, or working with offshore teams, these take on a level of importance that you unfortunately cannot ignore.
There's a pile of other stuff, of course. Data modeling, software architecture, packaging, deployment, languages, the UML, optimization, encryption, key management and certif
John