macOS Making the transition from "hacker" to "engineer"

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.

foidulus said:

and then code something up(using a lot of prints to debug)

Click to expand...

I'll give you this little bit of advice though : Learn to use a debugger.

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

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.

Click to expand...

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.

Update, the OP managed a Ask Slashdot front page post :

http://ask.slashdot.org/story/12/02/01/0122249/ask-slashdot-transitioning-from-hacker-to-engineer

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

http://ask.slashdot.org/comments.pl?sid=2647821&cid=38888575

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.

Click to expand...

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 ?

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.

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.

foidulus said:

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

Click to expand...

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.

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.

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.

talmy said:

IMHO the only difference between a "hacker" and "engineer" is discipline.

Click to expand...

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

Knowing what makes code readable, maintainable and extendable are what makes a software engineer an ENGINEER rather than just a coder.

Click to expand...

I'd accept that as a pretty reasonable first pass definition of "discipline"...

Analog Kid said:

I'd accept that as a pretty reasonable first pass definition of "discipline"...

Click to expand...

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

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

Click to expand...

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.

MattInOz said:

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.

Click to expand...

^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 http://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