Go Back   MacRumors Forums > Apple Systems and Services > Programming > Mac Programming

Reply
 
Thread Tools Search this Thread Display Modes
Old Jan 31, 2012, 04:15 AM   #1
foidulus
macrumors 6502a
 
Join Date: Jan 2007
Making the transition from "hacker" to "engineer"

So I'm about to get my masters in CS 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 Computer Science algorithms, and then code something up(using a lot of prints to debug), do some basic testing and go with it.... Obviously something that works quite well in the academic environment but not in the "real world" obviously. 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" on the reading list, but anything else? How do you get out of the "hacker" mindset?

Thanks
foidulus is offline   0 Reply With Quote
Old Jan 31, 2012, 04:20 AM   #2
KnightWRX
macrumors Pentium
 
KnightWRX's Avatar
 
Join Date: Jan 2009
Location: Quebec, Canada
What makes you think you need to ? The "mindset" you described is pretty much what a programming gig is. Testing ? That's what Q&A departments are for.

Quote:
Originally Posted by foidulus View Post
and then code something up(using a lot of prints to debug)
I'll give you this little bit of advice though : Learn to use a debugger.
__________________
"What you leave behind is not what is engraved in stone monuments, but what is woven into the lives of others."
-- Pericles
KnightWRX is offline   0 Reply With Quote
Old Jan 31, 2012, 04:40 AM   #3
jiminaus
macrumors 65816
 
Join Date: Dec 2010
Location: Sydney
The difference between a programmer and a software engineer is methodology. A programmer will do as you do, hack away without much of a plan, relying on instinct/experience to get the end goal. A software engineer will use a developed and tested methodology. A great software company will constantly feedback their experiences into their methodology, so when you start you've got all the experience of those how have gone before you to back you up.

Early methodologies coming from academia were rubbish. They treated software engineering like other engineering, ignoring the unique nature of software. The Rational Unified Process is one such monstrosity. Before I discovered agile processes, I loved the fractal-nature of Catalysis.

The later agile methodologies are much better. I'm a great fan of behaviour-driven development.
jiminaus is offline   2 Reply With Quote
Old Jan 31, 2012, 05:50 AM   #4
KnightWRX
macrumors Pentium
 
KnightWRX's Avatar
 
Join Date: Jan 2009
Location: Quebec, Canada
Quote:
Originally Posted by jiminaus View Post
The difference between a programmer and a software engineer is methodology. A programmer will do as you do, hack away without much of a plan, relying on instinct/experience to get the end goal.
I don't think that's true. The truth of the matter is, a "software engineer" can be many things as software engineering is a broad umbrella of tasks and roles to get from customer requirements to finished products.

A programmer is a part of software engineering. You also have analysts (who turn requirements and needs into a usable set of specifications), of course the programmer (who takes the analysts' specifications and implements it in code), the designers (who do the UI bits if required by the system), then on to Q&A testers that run the regressions/conformity tests, then on to integrators that can get the thing installed in a customer's existing infrastructure.

In academia, you fit into all these roles as you take an assignment, turn the prof's instructions into specifications, code them up, debug/test them and then integrate them into a usable form for the professor to grade you. But in real life, you will eventually have to pick and choose what you want to do and you'll get sort of pigeonholed into that role.

I work with tons of people who computer science degrees whom I wouldn't trust around a computer. They are still part of our organisation in various documentation/bureaucratic roles that need filing and somehow, they manage to enjoy it. Software engineering and IT are all much bigger than the technical aspect of it.
__________________
"What you leave behind is not what is engraved in stone monuments, but what is woven into the lives of others."
-- Pericles
KnightWRX is offline   0 Reply With Quote
Old Feb 1, 2012, 06:32 AM   #5
KnightWRX
macrumors Pentium
 
KnightWRX's Avatar
 
Join Date: Jan 2009
Location: Quebec, Canada
Update, the OP managed a Ask Slashdot front page post :

http://ask.slashdot.org/story/12/02/...er-to-engineer

See, I wasn't wrong about the debugger instead of prints

http://ask.slashdot.org/comments.pl?...1&cid=38888575
Quote:
Secondly, you already know this answer by the way you phrase your question: Stop doing prints for debugging and use a debugger, that's it's job. You'll remove years of pain and anguish from your working life. Anecdotally: our "debug by print" hire gave up trying to keep up with the "debugger guys" after only a few months and left the company voluntarily, despite our suggestion that his debugging methodology is painfully slow.
So OP, what did you get out of this thread and the Slashdot post ? Is your mind more at ease now that you realise that "hacker" and "engineer" don't have to be worlds apart or polar opposites ?
__________________
"What you leave behind is not what is engraved in stone monuments, but what is woven into the lives of others."
-- Pericles
KnightWRX is offline   0 Reply With Quote
Old Feb 1, 2012, 11:58 AM   #6
Mac_Max
macrumors 6502
 
Join Date: Mar 2004
The number one thing you can do is write software. Lots and lots of it. Write little programs that do anything and everything. Experience is the number one thing that will help you. Theory is wonderful but useless until you know its implications and implementation.

One thing that I feel helps you become a good engineer, is being able to decide when "Worse is Better" and when creating a masterpiece is appropriate. Really that's just an extension of knowing how to pick your battles. Academics tend to chant about building these theoretically perfect programs; code cathedrals so to speak. Sometimes that's just not possible and the best thing you can do is write your own code as best you can and hope down the line some refactoring is done to the rest of the project (especially when you inherit the program from someone else and have to add x feature in y days when you really need z days where z > y).

Skill-wise, something that has helped me is reading blogs with a high signal to noise ratio. Don't follow them religiously (writing code trumps reading about writing code), instead use them to get another point of view to compare and contrast with what you already know. It's a bit arrogant to assume that your implementation style is *always* correct so tempering your experience with that of others (i.e. finding a mentor) is important. It might take some time to figure out who to listen to (Joel Spolsky, Jeff Attwood, and Patrick McKenzie are pretty good IMO), especially since there are a lot of people who want the fanfare that actual experts get but really don't have the chops to say anything important.

In terms of reading material:

"Apprenticeship Patterns" gave me a lot of good advice that helped me when switching from school to the workforce.

http://ofps.oreilly.com/titles/9780596518387/

My favorites of course being "Be the worst" and building breakable toys.

The latter has been a huge help to me. I'm primarily a .Net developer but learning iOS programing really helped me iron out how to do a good MVC/MVP/MVVM design on Windows.

In addition there are the usual books people should read, Design Patterns, Code Complete, etc. Pick them up at your leisure and enjoy them.
Mac_Max is offline   0 Reply With Quote
Old Feb 1, 2012, 01:12 PM   #7
Analog Kid
macrumors 68030
 
Analog Kid's Avatar
 
Join Date: Mar 2003
If you know enough to ask that question, you'll do fine. You already understand that your personal methodologies will need to change to fit your new environment which puts you well ahead of most people coming out of school-- maybe that's the benefit of having spent time outside academics already.

Every company does things differently. If you're making pacemakers, they're going to be pretty detail oriented and rigorous. If you're a small start up trying to get to market before everyone else with the same idea then it'll all be about throughput and cleaning up your messes after the fact. Whatever the corporate culture is where you go, they'll probably have their own set of best practices, and they're likely to be pretty stern about imposing them on you so don't worry too much about needing to figure it out yourself.

Sometimes companies hire out of college so the company can learn something new, and sometimes there's pushback against the "new ways"-- try to figure out what they expect from you.

The hardest thing to adapt to is working with others-- you'll have to read and understand their code, and write your code in a way that's understandable to them. You may have to compromise where you prefer to put your curly braces after an if/else for the sake of harmony. Within your group, forging personal relationships is just as important as writing good code-- your code will never be perfect but, like in any relationship, those around you will be more flexible if they like you. You're also more likely to be forgiven if you're forgiving. I've seen some really good coders undermined by their lack of interpersonal skills.

That's harder to do when you're sharing code across groups. One thing I've learned after years of getting into these arguments is that every group accuses every other of not doing their software "right", or not documenting enough, or not commenting properly, but when you get inside of any group they're just as guilty. Keep that in mind when you go through your first code review-- fix what you're asked to, but don't take it as a personal failing.
__________________
Only trolls use the word "fanboy".
Analog Kid is offline   0 Reply With Quote
Old Feb 1, 2012, 03:09 PM   #8
thundersteele
macrumors 68030
 
Join Date: Oct 2011
Quote:
Originally Posted by foidulus View Post
[...] I take a problem, sketch together a rough solution using the appropriate Computer Science algorithms, and then code something up(using a lot of prints to debug), do some basic testing and go with it....[...]
I think you're on a good way. Making a plan before starting to code is probably the most important step. I would expect that as you become more experienced, the time spent planning will increase, and the time spent writing code will go down.
thundersteele is offline   0 Reply With Quote
Old Feb 1, 2012, 03:12 PM   #9
mydogisbox
macrumors member
 
Join Date: Jan 2011
There are a number of topics/books that would be helpful to you:

Pragmatic Programmer is a good book on various programming topics.
Something about design patterns (Head First Design Patterns is insulting to read, but still contains a lot of good, easy to understand material)

Apart from that, Pragmatic Programmer has a lot of good references to other things about which to learn.
mydogisbox is offline   0 Reply With Quote
Old Feb 1, 2012, 03:28 PM   #10
talmy
macrumors 68040
 
talmy's Avatar
 
Join Date: Oct 2009
Location: Oregon
What's in a name anyway? When I was in college I got degrees in "Electrical Engineering", there was no such thing as a "Software Engineering" or "Computer Engineering" and "Computer Science" was a graduate degree program. "Software Engineers" were usually either Electrical Engineers or Mathematicians or got into the field through some back door, having some unrelated liberal arts degree. My son got a Computer Science degree a dozen years ago and never writes any programs.

IMHO the only difference between a "hacker" and "engineer" is discipline.
__________________
27" i7 iMac, 15" MacBook Pro, Mac mini with Mavericks Server, 5 other Macs and an unused Apple TV.
talmy is offline   0 Reply With Quote
Old Feb 1, 2012, 03:34 PM   #11
mydogisbox
macrumors member
 
Join Date: Jan 2011
Quote:
Originally Posted by talmy View Post
IMHO the only difference between a "hacker" and "engineer" is discipline.
I'm going to disagree a great deal. From what the OP said, he has no experience maintaining software long-term. THIS is a large part of what it means to be an engineer that hackers have no part in. Maintainability, extendability and readability are things that you probably won't learn and don't need if you're writing use-once-and-throw-it-away software. Knowing what makes code readable, maintainable and extendable are what makes a software engineer an ENGINEER rather than just a coder.
mydogisbox is offline   0 Reply With Quote
Old Feb 1, 2012, 04:21 PM   #12
Analog Kid
macrumors 68030
 
Analog Kid's Avatar
 
Join Date: Mar 2003
Quote:
Originally Posted by mydogisbox View Post
Knowing what makes code readable, maintainable and extendable are what makes a software engineer an ENGINEER rather than just a coder.
I'd accept that as a pretty reasonable first pass definition of "discipline"...
__________________
Only trolls use the word "fanboy".
Analog Kid is offline   1 Reply With Quote
Old Feb 1, 2012, 07:42 PM   #13
mydogisbox
macrumors member
 
Join Date: Jan 2011
Quote:
Originally Posted by Analog Kid View Post
I'd accept that as a pretty reasonable first pass definition of "discipline"...
The two seem very different to me. I would say discipline is about consistency in doing the right thing (this can go with doing pretty much anything at all), while the list I gave is the specific contents of what the right thing consists of when it comes to creating, maintaining and extending large pieces of software. If discipline is what makes an engineer, then system admins are engineers...(at least the good ones are).
mydogisbox is offline   0 Reply With Quote
Old Feb 2, 2012, 12:22 AM   #14
MattInOz
macrumors 68030
 
MattInOz's Avatar
 
Join Date: Jan 2006
Location: Sydney
Quote:
Originally Posted by mydogisbox View Post
The two seem very different to me. I would say discipline is about consistency in doing the right thing (this can go with doing pretty much anything at all), while the list I gave is the specific contents of what the right thing consists of when it comes to creating, maintaining and extending large pieces of software. If discipline is what makes an engineer, then system admins are engineers...(at least the good ones are).
Not coming from a Computer Engineering background it seems most of the things discussed here are really general professionalism. Just tweaked to suit a specific profession. Respect for the Project and the team, which leads you to act in a way that builds on the collective work and more so to work in a way that helps other to build on your work.
__________________
There is no such thing as "Collective Wisdom"
[ iPhone 5s, iPad Mini, 13" MacBookPro 2.7Ghz, 27"Al iMac i7, Black MacBook 13"]
MattInOz is online now   0 Reply With Quote
Old Feb 10, 2012, 07:12 PM   #15
displaced
macrumors 65816
 
displaced's Avatar
 
Join Date: Jun 2003
Location: Gravesend, United Kingdom
Send a message via AIM to displaced Send a message via MSN to displaced Send a message via Skype™ to displaced
Quote:
Originally Posted by MattInOz View Post
Not coming from a Computer Engineering background it seems most of the things discussed here are really general professionalism. Just tweaked to suit a specific profession. Respect for the Project and the team, which leads you to act in a way that builds on the collective work and more so to work in a way that helps other to build on your work.
^This...

Write clear code. Be verbose. Don't try to be clever with obtuse 'cool' code. Think about what your code might need to do in future and code with that in mind. But don't over-engineer your code so that every eventuality is covered. You'll never manage that and will tie yourself and your code in knots trying to do so. Instead, write the least code possible to perform a task but structure your code smartly so that it can be built on with ease.

Use you comments to explain 'why' and to a lesser extent, 'what'. Never 'how'. If you need to explain how your code works in the comments, then your code is obtuse and should be simplified. Comments give context - explain why the code's doing what it's doing. A method or class comment should explain why that code exists.

Learn how to be great at all the other stuff that isn't coding. Learn a ticket tracking system inside-out and upside down (we use www.redmine.org). Learn how to write good user stories, 'specs', bug reports and enhancement requests. Always write as if someone else needs to understand, even if you're the only person that'll ever read it.

Learn version control. Branching, tagging, reverting and merging. Play with Continuous Integration systems and get a good handle on why both CI and version control are awesome.

Write both end-user and tech documentation. It makes you look at your software from a different angle and show you where you can improve.

Find out what's the best logging framework for the language and platforms you're using. I can have a mobile app crash on the other side of the world and I'll instantly get a full stack trace, log content, system, environment and state information logged as a crash report in our ticket tracking system. If your code's crying with pain it should be telling you where it hurts.

... and there's more of course
__________________
CONGRATURATION! YOU SUCCESS!
A WINNER IS YOU!
BUT OUR GIRAFFE IS IN ANOTHER CASTLE!
displaced is offline   0 Reply With Quote

Reply
MacRumors Forums > Apple Systems and Services > Programming > Mac Programming

Tags
programming career

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Similar Threads
thread Thread Starter Forum Replies Last Post
Report Claims Beats Acquisition to Bring "Culturally Aware" Managers to Apple, Manage Subscription Music Transition MacRumors MacRumors.com News Discussion 309 May 26, 2014 02:24 PM
Making transition from 13" MacBook Pro to 11" MacBook Air rsg1010 MacBook Air 10 Jan 24, 2014 06:13 PM
Total Computer Files Show Up In Folders, All "Go" Links, & are copied to hacker victim2014 iMac 4 Jan 5, 2014 12:56 PM
2010 27" iMac screen issue..."dirty", "cloudy", image retention issues MMcCraryNJ iMac 1 May 18, 2013 04:02 PM
Start a new tab similar to "iOS blog" and "Mac blog" but make it "IPhone Leaks?" Dewroo Site and Forum Feedback 2 Aug 23, 2012 09:47 AM

Forum Jump

All times are GMT -5. The time now is 09:36 PM.

Mac Rumors | Mac | iPhone | iPhone Game Reviews | iPhone Apps

Mobile Version | Fixed | Fluid | Fluid HD
Copyright 2002-2013, MacRumors.com, LLC