Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: Transitioning From 'Hacker' To 'Engineer'?

Soulskill posted more than 2 years ago | from the learn-how-to-sit-through-endless-meetings dept.

Programming 446

antifoidulus writes "I'm about to get my masters in Computer Science and start out (again) in the 'real world.' I already have a job lined up, but there is one thing that is really nagging me. Since my academic work has focused almost solely on computer science and not software engineering per se, I'm really still a 'hacker,' meaning I take a problem, sketch together a rough solution using the appropriate CS algorithms, and then code something up (using a lot of prints to debug). I do some basic testing and then go with it. Obviously, something like that works quite well in the academic environment, but not in the 'real world.' Even at my previous job, which was sort of a jack-of-all-trades (sysadmin, security, support, and programming), the testing procedures were not particularly rigorous, and as a result I don't think I'm really mature as an 'engineer.' So my question to the community is: how do you make the transition from hacker (in the positive sense) to a real engineer. Obviously the 'Mythical Man Month' is on the reading list, but would you recommend anything else? How do you get out of the 'hacker' mindset?"

Sorry! There are no comments related to the filter you selected.

srsly (0, Insightful)

Anonymous Coward | more than 2 years ago | (#38887323)

the heck are you talking about? nobody in the 'real world' is any different. hacker? give me a break dude.

Re:srsly (5, Insightful)

Anonymous Coward | more than 2 years ago | (#38887647)

>nobody in the 'real world' is any different

And the public wonders why most software is bug-ridden, badly designed shite.

Re:srsly (0)

Anonymous Coward | more than 2 years ago | (#38887679)

Yeah this. Even as a pos "operator" in my teens, we'd have crap cobbled together by some moron programmer that couldn't get it 100% right in test and stick the fix they were called in for into production the same night if something critical crashed. In a few hundred employee company. It's all hacking, don't imagine it's not and psych yourself out.

Take a Test. (1)

0100010001010011 (652467) | more than 2 years ago | (#38887789)

Take the FE (and the Canadian/European) Equivalent and tada. You can call yourself an engineer.

Reading List (5, Informative)

Anonymous Coward | more than 2 years ago | (#38887333)

Add Code Complete to the reading list as well as The Pragmatic Programmer

Is you is, or is you ain't, a black people? (-1, Offtopic)

blackpeoplemeet (2563129) | more than 2 years ago | (#38887341)

BlackPeopleMeet.com is the largest black dating site for black singles in the U.S. Founded in 2002, BlackPeopleMeet.com has built the largest community of African-American singles looking for love, relationships, friendship and dates. Our mission is simple: Creating Relationships. Connecting Lives.

Black dating has never been so easy. BlackPeopleMeet provides a simple, safe and fun atmosphere which makes it easy to quickly view and contact thousands of black singles in your area. Our one of a kind profile system allows members to setup audio, video, photo albums and much more. All the features you need to meet black men and black women are at your fingertips. Send flirts, send messages, use our live chat, post and browse pictures, and much more. Create your free profile [blackpeoplemeet.com] and search our black personals for exactly what you want.

If you have never experienced the power of internet dating you are missing out on an incredible opportunity. Beyond typical online dating, BlackPeopleMeet is a focused community dedicated to black dating. No need to bother with any other dating sites. Millions of singles are trying online dating sites and if you want to be a part of the largest black dating site in America and want to meet black singles in your area, sign up now [blackpeoplemeet.com] !

User acceptance testing (1)

Relayman (1068986) | more than 2 years ago | (#38887343)

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?

Don't worry (3, Interesting)

jawtheshark (198669) | more than 2 years ago | (#38887349)

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.

Re:Don't worry (1, Funny)

glebovitz (202712) | more than 2 years ago | (#38887585)

Sorry, but we reserve the GUI design jobs for Monkeys and typewriters.

Re:Don't worry (3, Funny)

ozmanjusri (601766) | more than 2 years ago | (#38887719)

Huh? What do the MCSEs do then?

Re:Don't worry (0)

Anonymous Coward | more than 2 years ago | (#38887819)

Who do you thing get's the monkey's their bananas?

Re:Don't worry (5, Insightful)

Fujisawa Sensei (207127) | more than 2 years ago | (#38887847)

Why is it people seem to think GUIs should be done by junior developers?

The front end code has to be the biggest pain in the ass out there.

Ooops I think I just gave away the secret.

Be a hacker (5, Insightful)

cryfreedomlove (929828) | more than 2 years ago | (#38887351)

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.

Huh? (5, Insightful)

Gorobei (127755) | more than 2 years ago | (#38887357)

If you can actually design a solution, throw together a suite of unit tests (that ideally show the basic API,) and deploy it to production, you are already ahead of 95% of the "software engineers."

Re:Huh? (0)

Anonymous Coward | more than 2 years ago | (#38887499)

This ^^^ If you're really concerned about testing just slam your software through as many static code analysis tools as you can get and go through it. Of course depending on what you get you're going to end up with a lot of stupid warnings and such, but you can still catch a ton of bugs fairly efficiently this way.

Re:Huh? (2)

adolf (21054) | more than 2 years ago | (#38887519)

This.

The guy is describing a process that actually produces things that work.

He should just stick with that, adjusting as he goes and keeping an open mind. If a more complex process is needed to get a reliable and working result, it will avail itself.

Re:Huh? (3, Insightful)

starfishsystems (834319) | more than 2 years ago | (#38887681)

Adding to this, I'd observe that most of the time, especially when starting out, you'll find that you have to work within the prevailing procedures and resources and organizational culture that define your workplace. If they do waterfall, guess what? You do waterfall.

It's great to end up somewhere that wants you to lead the way forward, but even then you have to develop the social skill of bringing people along with you by earning their respect and trust. Most people want to see you "do it their way" first in order to prove yourself.

What do you think "engineering" is? (4, Insightful)

mcrbids (148650) | more than 2 years ago | (#38887371)

An "engineer" is somebody who takes the time to understand a problem, and creates something to solve that.

Having done software from scales ranging from "quick shopping cart application" to enterprise scale organizational relationship management software, the only real difference between the two is that with the latter, you create a large number of smaller projects roughly the size of the aforementioned shopping cart application, except that the "users" are often other pieces of the same system. In larger systems, you'll be talking with other developers who have built or manage the pieces your parts will communicate with. You'll read more documentation, and it will be generally of higher quality than the shopping cart scripts.

Don't *ever* lose the "hacker" mentality - exactly what you described is what software engineering is. The toughest part IMHO is getting to an understanding of what the end user actually needs. That's far and away harder than all the other stuff, which boils down to implementation details once you understand the algorithms.

Re:What do you think "engineering" is? (4, Informative)

Anonymous Coward | more than 2 years ago | (#38887469)

I would add that the big difference between "hacking" and an engineering approach is a structured understanding of the problem. (As several people pointed out, you actually need an engineering degree and possibly a certification to be called an engineer.) Part of that involves using standard and well understood processes for problem solving, inventing and documenting new repeatable processes, measuring performance, and using that to inform the continued development of your processes.

Re:What do you think "engineering" is? (4, Funny)

wvmarle (1070040) | more than 2 years ago | (#38887829)

I would add that the big difference between "hacking" and an engineering approach is a structured understanding of the problem.

I may assume that the CS masters study has taken care of that "structured understanding" part. In other words: hacker + CS degree = software engineer.

Re:What do you think "engineering" is? (1)

Anonymous Coward | more than 2 years ago | (#38887959)

Not necessarily. That may give you the analytical tools to quantify the problem. That's the science part of computer science, where you learn to synthesize a hypothesis and test that hypothesis. Here's a concrete example. I'm going to build an object storage system because I have a better way to conduct distributed pattern matching. The science part of it involves conducting the experiment and aggregating the result. My method is 1.5 times faster than the best method previously available for a variety of data sets, blah, blah blah.

The engineering part of it is I'm going to turn my storage system into a SaaS offering. As part of that I'm going to use a defined process for developing the software, during which I will collect metrics to evaluate whether or not the process is good or can be improved. I'm going to define part of the process using XYX methodology as a basis, out of which I will tailor out some processes which will not add value to the final product. I know it is safe to tailor out these processes because there are quantitative evaluations of the process which indicate that there is substantially no difference in total defects, maintenance cost, or schedule impacts ....

BULL F*CKING SH*T. (-1)

Anonymous Coward | more than 2 years ago | (#38887373)

"Engineer" is the government buzz-word.

Thanks alot Microsoft. I've lost alot of work because I can't show to anyone that I am a certified Engineer of Microsoft software. It all went down-hill when this big corporation CEO's starting closing doors to homebrew and hobbyist sectors that they theirselves walked through and closed to prevent others from doing the same in competition.

STEVE JOBS: If you think different than me then you get fired.
WHAT PUBLIC THINKS OF STEVE JOBS: what a great innovator!

BILL GATES: I helped spread the most-used computer architecture by making my OS easier to use and easier to break that it's just everywhere.
WHAT PUBLIC THINKS OF BILL GATES: monopolist!

RCHARD STALMAN: I make software and give it away for free.
WHAT PUBLIC THINKS OF RICHARD STALMAN: who is this guy again? Never heard of him.

Hacker vs engineer (4, Insightful)

CruelKnave (1324841) | more than 2 years ago | (#38887381)

I never considered the two to be mutually exclusive.

development styles (1, Funny)

sneakyimp (1161443) | more than 2 years ago | (#38887383)

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.

Good Start (4, Informative)

orlanz (882574) | more than 2 years ago | (#38887389)

But really, that's for project management.

1) Go read up on the industry standard IDEs & debuggers for the programming environment you will be working in.
2) If your job is really consistent and stable (ie: Java programs day in day out), then go master your IDEs & debuggers. Learn their customization capabilities.
3) Learn to organize your personal code library and build up your core tool set in a way that is functionally reusable and searchable.
4) Learn to program your work in a way that adds to and complements #3.
5) Learn to document your code and processes.
6) Read a book on communicating to management (sry someone else will need to provide a good example), this will set you apart from your companions.

I meant to give you my 2 cents, but dropped a nickle... keep it. Good luck.

Try to get a real engineer as mentor (2, Informative)

Anonymous Coward | more than 2 years ago | (#38887399)

Well.. You need to find some real good engineers to work with and learn from them. :)

There are a lot of good coding examples open-source (Linux kernel) and you can learn from them too.. Practice makes things perfect.. Practice good coding habits.. Think more, code less, debug less. :)

Good luck..

~Self-learned Jack of all trades

Re:Try to get a real engineer as mentor (0)

Anonymous Coward | more than 2 years ago | (#38887477)

Still doesn't turn you into an engineer, you know, like one with an actual engineering degree.

Re:Try to get a real engineer as mentor (4, Insightful)

adolf (21054) | more than 2 years ago | (#38887597)

Still doesn't turn you into an engineer, you know, like one with an actual engineering degree.

Meh.

Which came first, the engineer or the engineering degree?

Re:Try to get a real engineer as mentor (2)

Mia'cova (691309) | more than 2 years ago | (#38887875)

A masters in CS is just as valid towards a "software engineer" job title as a similarly focused degree from an engineering dept. Different schools have different organizational structures. A software engineering degree from a CS dept is no less valuable than one that comes with a ring. You should absolutely not equate a "software engineer" as someone with a ring. That's not to say that ring-based engineers can't be good software engineers. I'm not in any way saying that. I'm just saying that more software engineers come out of math and cs faculties than engineering faculties with an "actual engineering degree".

you're already there (0)

Anonymous Coward | more than 2 years ago | (#38887411)

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.

just be a good learner (0)

Anonymous Coward | more than 2 years ago | (#38887413)

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.

don't sweat it (0)

Anonymous Coward | more than 2 years ago | (#38887417)

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.

You aren't an engineer (-1)

Anonymous Coward | more than 2 years ago | (#38887419)

You should stop trying to refer to yourself as an engineer unless you: (i) have an accredited engineering degree, e.g., an S.B., Eng.B., S.M., Eng.M., D.Eng., Ph.D., or Sc.D. in electrical engineering, computer engineering, bioengineering, and so forth, and (ii) are eligible to take, or already have passed, a professional engineering licensing exam, where appropriate.

Predictability (5, Insightful)

Okind (556066) | more than 2 years ago | (#38887421)

Being a software engineer instead of a hacker is all about predictability:

  • Predictable planning: have it done when you say it will be.
  • Software quality: use Test Driven Design to ensure your code behaves as it should.
  • Predictable deployments: practice and simplify deploying your code for systems.
  • Document the structure of your code, so the next guy knows what he's looking at.

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.

!Engineer (-1)

Anonymous Coward | more than 2 years ago | (#38887423)

To become a real engineer, do an engineering degree. Computer Science != Engineer. Just like a naturopath != Doctor.

Everyone seems to want to call themselves an engineer these days....

Don't sweat it! (0)

Anonymous Coward | more than 2 years ago | (#38887425)

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.

You get a job (5, Insightful)

phantomfive (622387) | more than 2 years ago | (#38887431)

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.

Re:You get a job (1)

Gorobei (127755) | more than 2 years ago | (#38887491)

Truer words were never spoken.

Not sure (1)

ctime (755868) | more than 2 years ago | (#38887433)

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.

Stay as a hacker (2)

unity100 (970058) | more than 2 years ago | (#38887437)

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.

It depends (0)

Anonymous Coward | more than 2 years ago | (#38887453)

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.

An engineer always put design above hackery (1)

itsybitsy (149808) | more than 2 years ago | (#38887455)

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.

GOF Design Patterns (3, Informative)

binarstu (720435) | more than 2 years ago | (#38887461)

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.

Difference is level of detail and corner cases (4, Insightful)

Sipper (462582) | more than 2 years ago | (#38887481)

I think the main difference between "hacker" and "engineer" is the level of detail and concerns on corner cases that you want your code to be able to handle and/or tolerate. Having worked as an engineer for some years, basically I boil down the job to three things -- 1) good clear communication of what the problem to solve actually is, 2) solving the problem such that the solution "meets spec", 3) trying to make sure that the solution continues to work within tolerance in any typical adverse conditions the solution needs to handle. Occasionally you may need to do some kind of formal verification that the solution will be wtihin tolerance in typical adverse conditions. With programming this verification might involve a test suite, code review, fuzzy input testing, memory leak testing, security audit, etc.

But in your particular situation it sounds like you're going to learn what you need on your own on the job one way or the other, so for now I'd say just relax and figure out what you need when you get there. i.e. I think you might be over-thinking this right now. ;-)

Aesthetic Sense (1)

sydneyfong (410107) | more than 2 years ago | (#38887493)

This is purely anecdotal experience, but people from academia tend to write code that is a bit more "ugly" than seasoned "software engineers". By "ugly", I mean the code works, but it's relatively less readable and harder to maintain and extend.

Other than that, it's pretty much the same thing, IMHO. There's nothing so magical/mythical about "software engineering", and practices between companies can be very different.

Re:Aesthetic Sense (0)

Anonymous Coward | more than 2 years ago | (#38887555)

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.

Hah. Definitely not the same thing. I work in a research institute and I look at academic code all day long. You've got files on one hand which are one gigantic function verses a correctly written one which is nicely decomposed. Guess who wrote the latter?

Re:Aesthetic Sense (1)

sydneyfong (410107) | more than 2 years ago | (#38887637)

By "ugly", I mean the code works, but it's relatively less readable and harder to maintain and extend.

Hate to quote myself. I'm violating my sig.

Empathy (2)

ProgGuy (2564779) | more than 2 years ago | (#38887503)

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.

Get a mentor (4, Interesting)

Mia'cova (691309) | more than 2 years ago | (#38887509)

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 :)

Keep hacking (0)

russotto (537200) | more than 2 years ago | (#38887523)

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.

code reading (0)

Anonymous Coward | more than 2 years ago | (#38887525)

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.

Hacking and Engineering (5, Interesting)

Crash McBang (551190) | more than 2 years ago | (#38887527)

Engineering a house:
1. Gather requirements
2. Write a spec
3. Design house to spec
4. Build house to design

Hacking a house:
1. Nail boards together
2. Step back
3. Is it a house yet?
4. No, go to 1

Both methods work, but I'd prefer the former to the latter...

Re:Hacking and Engineering (0)

Anonymous Coward | more than 2 years ago | (#38887723)

Both methods work, but I'd prefer the former to the latter...

Perhaps, but nobody expects an architect to put up with the client deciding halfway through that it shouldn't be a house, it should be an aircraft carrier. Then a week later, a skyscraper...

Re:Hacking and Engineering (0)

Anonymous Coward | more than 2 years ago | (#38887727)

I think it depends on the goal.

If i am trying to break something, a hack-together solution might work the best. Its not code that i am going to try and maintain.

A software program on the other hand is completely different. Requirements and design have a lot more importance.

Re:Hacking and Engineering (2)

El_Muerte_TDS (592157) | more than 2 years ago | (#38887883)

And professional software development is usually more like the latter than the former.

Re:Hacking and Engineering (1, Funny)

wvmarle (1070040) | more than 2 years ago | (#38887933)

LOL

The big difference with house vs. software is that when you nail some boards together it's quite permanent, and hard to remove and redo. I admit to do programming mainly alone the second line, but usually with something like a plan, and working quite targeted to it. More like:

1. Nail boards together.
2.Step back.
3. Location correct, all straight up and aligned with the rest? goto 6.
4. Redo latest board, and/or adjust previous boards.
5. goto 3.
6. Looks like a livable house? end.
7. goto 1.

But then without the goto statements :-)

Maintainability (4, Insightful)

spiffmastercow (1001386) | more than 2 years ago | (#38887531)

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.

I'd say your number one goal is (2)

NotSoHeavyD3 (1400425) | more than 2 years ago | (#38887539)

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.)

Learn to read code (3, Interesting)

donscarletti (569232) | more than 2 years ago | (#38887545)

Welcome to the farse of "Software Engineering", the sooner you realise that the way things happen in the real world is just (as you say) hacking stuff together and debugging it the better. The only added fun that you will have no idea what 70% of your codebase does and neither does anyone else.

While Software Engineering never provided any credible way of _building_ the systems, what it used to do is provide ways where you could find out exactly what you need before you start building it. These days we have Agile instead, so we don't do that, we just pick an idea at random and hope to god it's either right or we can change it.

My advice: Learn to read code. Learn to find out what the system actually does, not what the comments says it does. Learn to read it then work out how to slowly change it into what you need. It's the difference between the respected senior guy who fixes the problems and the detested junior guy who creates them. I work with a commercial 3D game engine and the fact I know every line of it is worth far more to anyone than how many lines I can myself write in a day.

Testing and readability (2)

Fastolfe (1470) | more than 2 years ago | (#38887549)

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... (0)

Anonymous Coward | more than 2 years ago | (#38887559)

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.

Deliver. (0)

Anonymous Coward | more than 2 years ago | (#38887565)

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.

all making sense until mythical man month (2)

Surt (22457) | more than 2 years ago | (#38887573)

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.

Come on. (0)

slasho81 (455509) | more than 2 years ago | (#38887579)

Sounds like you have a semantic crisis.

Hacker is used as an insult (0)

Anonymous Coward | more than 2 years ago | (#38887583)

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.

Agile vs. Waterfall (3, Insightful)

Tony Isaac (1301187) | more than 2 years ago | (#38887587)

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!

Read Code Complete (0)

Anonymous Coward | more than 2 years ago | (#38887593)

Code Complete [amazon.com] 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.

Are you asking how to get more consistent results? (1)

unimacs (597299) | more than 2 years ago | (#38887601)

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.

I had the SAME question (0)

Anonymous Coward | more than 2 years ago | (#38887605)

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.

Engineer (3, Insightful)

Wolfling1 (1808594) | more than 2 years ago | (#38887617)

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.

Re:Engineer (1)

tigersha (151319) | more than 2 years ago | (#38887825)

> The biggest problem most techs face is their own arrogance.

Bingo. Don't look down on your peers. You are not better than them just because you like vi.

EIT then PE test (0)

Anonymous Coward | more than 2 years ago | (#38887645)

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.

Think Inside the Box (1)

Mafiasecurity (2561885) | more than 2 years ago | (#38887661)

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.

Wrong (0)

Anonymous Coward | more than 2 years ago | (#38887957)

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.

pool game analogy (0)

Anonymous Coward | more than 2 years ago | (#38887663)

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.

Engineer's solution (1)

S3D (745318) | more than 2 years ago | (#38887687)

Academic concentrate on the finding out where his solution works. Engineer mostly concerned with situations what to do if it doesn't.

I'm in suspense. (0)

Anonymous Coward | more than 2 years ago | (#38887691)

Tell me how to hire engineers and what makes a good one... and the best interviewing strategies.

Coding practice (1)

glebovitz (202712) | more than 2 years ago | (#38887705)

I think experience on commercial projects allows you to develop better coding practices and develop skills for estimating project size. It usually takes 6 months to a year for one of our fresh masters level graduates to become fully productive.

At our company, we won't hire you unless we are pretty sure you can do the job. It is our responsibility to make sure you learn the skills to be productive.

Test Driven Development (2)

SplashMyBandit (1543257) | more than 2 years ago | (#38887721)

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).

Work for an Engineering company (1)

darkwing_bmf (178021) | more than 2 years ago | (#38887755)

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.

You have to specify SOFTWARE engineer (5, Funny)

Swampash (1131503) | more than 2 years ago | (#38887769)

So you don't get confused with a real, actual engineer.

Re:You have to specify SOFTWARE engineer (1)

H0p313ss (811249) | more than 2 years ago | (#38887991)

Agreed, I prefer to call myself a Software Alchemist.

It is kinda a grey area, but dont worry. (1)

patomuerto (90966) | more than 2 years ago | (#38887795)

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 [drdobbs.com]

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.

Have one such case right now (4, Interesting)

tigersha (151319) | more than 2 years ago | (#38887823)

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.

Should of went to a tech school CS is not for work (0)

Joe_Dragon (2206452) | more than 2 years ago | (#38887841)

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.

Starting out (1)

popsensation (1405041) | more than 2 years ago | (#38887855)

I think your question is good. There are a lot of problems with new developers and most of them revolve around the patterns and habits they get into working on projects which are difficult and impractical. I think the easiest way to get over that is start thinking about your time as money. Don't waste either.
  1. 1.) If you can't figure something out and you have a feeling it's easy for another team member to explain, check google/sources for 1 minute. If you don't find it that quick ask somebody. I can't express it enough, when new dev engineers ask questions under this rule set they are so much more efficient.
  2. 2.) When filling in a spec only consider algorithmic efficiency when it is more timely. Otherwise mark it //TODO - Could be more efficient
  3. 3.) Spend time getting acquainted with the libraries and tools available to you. Ask other engineers, they will gladly share their rig.
  4. 4.) When you think, 'someone on my team has probably done this', ASK. If they haven't write it into a shared libraries or utils that team members can use.
  5. 5.) Fitting more then one task on a line isn't better programming, it is usually annoying, do one thing at a time.

I hope that helps!

Software Engineering? (0)

Anonymous Coward | more than 2 years ago | (#38887895)

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.

Dealing with people (2)

Frans Faase (648933) | more than 2 years ago | (#38887897)

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.

There is nothing wrong with printf debugging (0)

Anonymous Coward | more than 2 years ago | (#38887899)

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.

Re:There is nothing wrong with printf debugging (1)

OrangeTide (124937) | more than 2 years ago | (#38888025)

I agree. Using printf debugging is just one of many tools for trouble shooting. It's not the end-all-be-all but nothing is. I tend to flip between printf debugging and full JTAG remote debugging with very little in between. (nothing against application debuggers, they can be another useful tool)

Prints can add delays in a program and made race conditions disappear, which can be quite frustrating. But I also find fancy debuggers add unusual behaviour to a program which often result in tracking down some inaccurate stack trace or causes multi-threaded programs to act in a single threaded way.

Custom hacks to do some data collection that you can dump without much overhead is a pretty helpful tool for debugging the tougher problems. Also what can be troublesome to debug are programs that don't crash or corrupt and just perform the wrong calculations, like in video and image codecs where you can easily introduce tiny floating point errors that are not immediately obvious.

do what you're good at (1)

Goldsmith (561202) | more than 2 years ago | (#38887929)

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.

Time. (2)

forkfail (228161) | more than 2 years ago | (#38887937)

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.

In the words of chess master Emanuel Lasker... (1)

Druid Squirrel (264250) | more than 2 years ago | (#38887967)

"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.

Teamwork (1)

eonwing (934274) | more than 2 years ago | (#38887977)

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 (4, Informative)

notandor (807997) | more than 2 years ago | (#38887983)

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).

maturity (1)

jesterman (932975) | more than 2 years ago | (#38888003)

"I don't think I'm really mature as an 'engineer'"

Don't worry. The field is not mature either.

The Doomed Discipline (1)

WeirdAlchemy (2530168) | more than 2 years ago | (#38888015)

One of the most eye-opening things I've read is On the cruelty of really teaching computer science [utexas.edu] by Edsger Dijkstra [wikipedia.org] , 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.'"

You find someone you think is a good engineer (1)

creative_Righter (834378) | more than 2 years ago | (#38888017)

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.

en-gi-neer—n. (1)

macshit (157376) | more than 2 years ago | (#38888029)

"Engineer": "Hacker" with enough scars.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?