Slashdot Mirror
Ask Slashdot: Transitioning From 'Hacker' To 'Engineer'?
antifoidulus writes "I'm about to get my masters in Computer Science and start out (again) in the 'real world.' I already have a job lined up, but there is one thing that is really nagging me. Since my academic work has focused almost solely on computer science and not software engineering per se, I'm really still a 'hacker,' meaning I take a problem, sketch together a rough solution using the appropriate CS algorithms, and then code something up (using a lot of prints to debug). I do some basic testing and then go with it. Obviously, something like that works quite well in the academic environment, but not in the 'real world.' Even at my previous job, which was sort of a jack-of-all-trades (sysadmin, security, support, and programming), the testing procedures were not particularly rigorous, and as a result I don't think I'm really mature as an 'engineer.' So my question to the community is: how do you make the transition from hacker (in the positive sense) to a real engineer. Obviously the 'Mythical Man Month' is on the reading list, but would you recommend anything else? How do you get out of the 'hacker' mindset?"
Add Code Complete to the reading list as well as The Pragmatic Programmer
Other than possibly a more thorough job of testing, the only thing I would add is user acceptance testing. Does the program do what the user thinks it should?
If I used a sig over again, would anyone notice?
Don't worry. You don't seriously think you'll get to do any "software engineering" when you start, do you. You'll start -like everyone- programming fontends/GUIs, and let the more interesting parts to the more senior people.
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
I'm not sure you should try to get out of the 'hacker' mindset. Iterative innovation and continuous integration is much more rewarding than any waterfall approach. Good luck and follow your heart.
If you can actually design a solution, throw together a suite of unit tests (that ideally show the basic API,) and deploy it to production, you are already ahead of 95% of the "software engineers."
An "engineer" is somebody who takes the time to understand a problem, and creates something to solve that.
Having done software from scales ranging from "quick shopping cart application" to enterprise scale organizational relationship management software, the only real difference between the two is that with the latter, you create a large number of smaller projects roughly the size of the aforementioned shopping cart application, except that the "users" are often other pieces of the same system. In larger systems, you'll be talking with other developers who have built or manage the pieces your parts will communicate with. You'll read more documentation, and it will be generally of higher quality than the shopping cart scripts.
Don't *ever* lose the "hacker" mentality - exactly what you described is what software engineering is. The toughest part IMHO is getting to an understanding of what the end user actually needs. That's far and away harder than all the other stuff, which boils down to implementation details once you understand the algorithms.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
I never considered the two to be mutually exclusive.
Learn to bullshit about development methods like agile, waterfall, etc. Learn to estimate project costs before a project starts. Expect to spend lots of time making these estimates without getting paid for them only to be told that your estimate is too expensive and you've been beat out by some 'hacker' from Asia or Eastern Europe where the cost of living is a fraction of yours.
If you play your cards right, you will graduate from programmer of the line to 'system architect' or something like that where you tell other programmers what to do.
But really, that's for project management.
1) Go read up on the industry standard IDEs & debuggers for the programming environment you will be working in.
2) If your job is really consistent and stable (ie: Java programs day in day out), then go master your IDEs & debuggers. Learn their customization capabilities.
3) Learn to organize your personal code library and build up your core tool set in a way that is functionally reusable and searchable.
4) Learn to program your work in a way that adds to and complements #3.
5) Learn to document your code and processes.
6) Read a book on communicating to management (sry someone else will need to provide a good example), this will set you apart from your companions.
I meant to give you my 2 cents, but dropped a nickle... keep it. Good luck.
Well.. You need to find some real good engineers to work with and learn from them. :)
There are a lot of good coding examples open-source (Linux kernel) and you can learn from them too.. Practice makes things perfect.. Practice good coding habits.. Think more, code less, debug less. :)
Good luck..
~Self-learned Jack of all trades
Being a software engineer instead of a hacker is all about predictability:
There's more to each of these items, of course, but it's all about making it simple (KISS) and predictable. This sets a software engineer apart from a mere hacker.
For experience, there is no substitute for working 8 hours a day, week after week, trying to write programs and make them better. Always be thinking about how you can improve the program you are working on (even if you don't actually have the time to do it), and you will quickly improve.
Even if you are just stuck debugging someone else's code (90% of what I've done over the last year), the process of doing that 1,600 hours a year will really improve your skills.
"First they came for the slanderers and i said nothing."
Well, other than know your shit and stop whining, I don't know. You haven't said what your title will be or what you will be doing. Maybe by learning operations as much as you can and about how things work today rather than try to design new pie in the sky systems. Everything needs to be gradual. Also, learn how to document for gods sakes. Try to keep things simple, yet effective. Re-use proven concepts. Managing projects is always a trade off a effectiveness and efficiency, many people forget when they design a new system how inefficient it will be for the rest of the company or systems to do their jobs with the new system. Those designers are assholes.
Also, most of the technical "principles" and "distinguished architects" designing systems are pathologically overconfident in themselves. You'll be implementing their ideas for many years to come anyways.
for
Since my academic work has focused almost solely on computer science and not software engineering per se, I'm really still a 'hacker,' meaning I take a problem, sketch together a rough solution using the appropriate CS algorithms, and then code something up (using a lot of prints to debug)
this is what you will be doing throughout your entire career. time constraints, budget constraints, legal constraints, XYZ constraints - there will always be something effecting you to have to do it the hack way.
Read radical news here
Building a prototype by the seat of your hacking pants is one thing, working in start ups and corporate IT departments does require you to get serious and drop the hackery and adopt a professional attitude towards software development. Become an engineer committed to the design of the system that works for your client's needs.
You'll of course, at any company where work has been done, discover that hackers have already been at the company likely creating a mess. One thing that successful software engineers do is clean up the hackery messes by organizing the systems they left behind. When creating new systems that are to last a long time then organize it the best that can be done with a sane and clear design to get the job done and make it easy to maintain and grow.
It's not that you'll never use hacks along the way but it's best to never put those into production code. It will likely come back and bite you and the client more often than not.
Testing Suites help a lot. Create them. Use them.
Oh, get really good at debugging the systems. Listen to other people. Ask them questions. Be humble when you don't know and thank people for assisting you. It pays off and makes you indispensable.
I'd recommend reading the classic software design book Design Patterns by the "Gang of Four" (Gamma, Helm, Johnson and Vlissides). I know that "design patterns" has become something of an overused buzzword, but that book is without a doubt one of the best books about software architecture I have ever read. It helps you learn how to think about designing object-oriented software in ways that result in re-usable, understandable code. I don't think I really saw the power of good object-oriented design until I read Design Patterns.
I think the main difference between "hacker" and "engineer" is the level of detail and concerns on corner cases that you want your code to be able to handle and/or tolerate. Having worked as an engineer for some years, basically I boil down the job to three things -- 1) good clear communication of what the problem to solve actually is, 2) solving the problem such that the solution "meets spec", 3) trying to make sure that the solution continues to work within tolerance in any typical adverse conditions the solution needs to handle. Occasionally you may need to do some kind of formal verification that the solution will be wtihin tolerance in typical adverse conditions. With programming this verification might involve a test suite, code review, fuzzy input testing, memory leak testing, security audit, etc.
But in your particular situation it sounds like you're going to learn what you need on your own on the job one way or the other, so for now I'd say just relax and figure out what you need when you get there. i.e. I think you might be over-thinking this right now. ;-)
This is purely anecdotal experience, but people from academia tend to write code that is a bit more "ugly" than seasoned "software engineers". By "ugly", I mean the code works, but it's relatively less readable and harder to maintain and extend.
Other than that, it's pretty much the same thing, IMHO. There's nothing so magical/mythical about "software engineering", and practices between companies can be very different.
Don't quote me on this.
When you work in a team, try to put yourself into other people shoe to try and understand how they see the project you are working on. This will let you learn about how software is perceived by others and the place it has in a business environment. It will also teach you to play nice with others, which is a great quality.
Find someone in your new office to show you the ropes. Every major piece of software tends to have its own issues. For server software you might be looking at analyzing piles of log output. For gaming it might be real time perf metrics. Chances are, the biggest thing to get comfortable with is your debugging->fixing->building->testing->checkin cycle. Make sure you figure out how to get the road blocks out of your way. If you're working on something painful where there's a ton of time wasted rebuilding to try out your ideas, maybe there's a better way to build/patch in a more granular way. Your peers will also be interested in any process improvements. If you can optimize and speed up a process that makes you more effective, share it with the team. People really respect and appreciate anyone who can make their life easier.
And *really* spend some serious time trying to learn your software's object model, lifecycles, and data structures. When you start there will be an overwhelming amount of information. You need to accept that. But once you've got a bit of a foothold, CONTINUE learning. You want to be an expert. It takes discipline to get a broad and deep enough understanding to truly be efficient and effective. Be interested in the work of your closest peers. Chances are, what they have learned over the years can be incredibly helpful to enhancing your efficiency. At the end of the day, you'll be primarily judged on reliability and throughput. Whatever you can do to meet your goals, the better! And never be afraid to get help. It doesn't matter if someone helps you finish something. All your manager cares about is that the task is done. If they assign it to you, you are responsible for driving that task to completion. If you don't have an a clear idea of how to do something, that's your cue to immediately find someone to brainstorm with.
And career-wise, it's easier to advance in the earlier years. So when optimizing towards success and a happy retirement, a lot of it comes down to how quickly you can advance in your early years. Down the road, it's as much time as ability. To start with, it's all work ethic. Put in that extra 10% to be the hardest worker and you'll be getting promotions year after year. Work through those lower levels as fast as you can so you can enjoy the rest.
Good luck :)
Engineering a house:
1. Gather requirements
2. Write a spec
3. Design house to spec
4. Build house to design
Hacking a house:
1. Nail boards together
2. Step back
3. Is it a house yet?
4. No, go to 1
Both methods work, but I'd prefer the former to the latter...
To put a witty saying into 120 characters, jst rmv ll th vwls.
Ignore the assholes. Debates about the meaning of 'Engineer' aside, what you really need to learn is maintainability, testing, and patience. Writ code that you wouldn't mind maintaining if you weren't the original author. Don't repeat yourself. Follow coding standards. And most of all, learn to work with others and leave your ego at the door. That's what separates a 'hacker' from a professional.
To make your code readable. I mean so that if you came back to your code in 6 months you wouldn't have to completely reverse engineer it to figure out what it does.(Since I'm guessing you effectively threw away any coding efforts you did for your projects about 30 seconds after it got graded.) If you write your code with that in mind after a while you'll be fine.(Because believe me, either you'll be coming back to your old code or you'll be coming back to somebody else's old code and it sucks when it looks like the app was put together with figurative chewing gum and duck tape.)
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
Welcome to the farse of "Software Engineering", the sooner you realise that the way things happen in the real world is just (as you say) hacking stuff together and debugging it the better. The only added fun that you will have no idea what 70% of your codebase does and neither does anyone else.
While Software Engineering never provided any credible way of _building_ the systems, what it used to do is provide ways where you could find out exactly what you need before you start building it. These days we have Agile instead, so we don't do that, we just pick an idea at random and hope to god it's either right or we can change it.
My advice: Learn to read code. Learn to find out what the system actually does, not what the comments says it does. Learn to read it then work out how to slowly change it into what you need. It's the difference between the respected senior guy who fixes the problems and the detested junior guy who creates them. I work with a commercial 3D game engine and the fact I know every line of it is worth far more to anyone than how many lines I can myself write in a day.
When Argumentum ad Hominem falls short, try Argumentum ad Matrem
You say you've done some "basic" testing, but one of the biggest challenges for me upon entering a "real" software development role was adapting to test-driven development. Even if you don't take this all the way and write up all of your unit tests before you start coding, you do have to completely re-think how you structure your software so that it can be testable at all. This means breaking up your functions not just into parts that make it more readable, but into parts that can be independently tested. Usually this means breaking out your dependencies into interfaces, so that they can be mocked out (oh, and learning how to mock things), avoiding side effects, that sort of thing.
Also focus on writing readable code. I usually make one or two passes after I think I've gotten everything written and refactor with an eye toward making everything readable and understandable.
That's more of a management book. If you want to get better at coding practices, you want a different library entirely. Try reading something like code complete or refactoring to patterns.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
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!
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.
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.
>nobody in the 'real world' is any different
And the public wonders why most software is bug-ridden, badly designed shite.
Engineers know the box. They know everything about inside the box and are experts about the box. Hackers know the box; however, they look at how they can change the box.
http://www.mafiasecurity.com maf
Academic concentrate on the finding out where his solution works. Engineer mostly concerned with situations what to do if it doesn't.
I think experience on commercial projects allows you to develop better coding practices and develop skills for estimating project size. It usually takes 6 months to a year for one of our fresh masters level graduates to become fully productive.
At our company, we won't hire you unless we are pretty sure you can do the job. It is our responsibility to make sure you learn the skills to be productive.
Learn about Test Driven Development (TDD). You don't need a book on it, simply use Google and learn about its importance for software quality, and learn how to use JUnit. Adopting TDD will change your development process and the way you develop software. Your software will be more correct, more reliable, you'll have an automated suite for maintaining it and your software will be better designed and more modular (required to be more testable). Once you get the "testing religion" your view on good development style will change (and you'll see that a lot of the software development "orthodox" wisdom is actually counter-productive to testing and what really matters when developing reliable software quickly).
On the job training of course. Work for a company that does Engineering and Manufacturing... preferably something like Aerospace where they have dedicated software testing teams and rigorous design documents.
So you don't get confused with a real, actual engineer.
Take the FE (and the Canadian/European) Equivalent and tada. You can call yourself an engineer.
I was in a similar situation a few years ago. This was the most useful article I found,
http://drdobbs.com/architecture-and-design/217701907
But really don't worry that you are not a verse in SE. I would say the majority who program have just a small working knowledge. The smartest thing to do is when you get to your job is ask what their processes are and what they expect. Use the terminology, like agile, cmmi, unit test, process development, etc. If they have a process or model they are following, they will be thrilled your asking. If they don't then hope they are all master programmers and everyone works well together.
I have secretly hidden some mispelled words in this post. Can you find them?
I have a hotshot hacker working for me right now who thinks he knows everything, but he is just a stupid little hacker who thinks his dick grows every time he uses vi. Don't be like that.
You are already on the right path: You recognized in yourself that you need to grow professionally and that you need to get away from the little dark screen and see how it fits into the world.
Three points:
* See the first for the trees
* Have the balls to say "I don't know"
* Education, education, education
Here is the most important thing to remember: A hacker sees his own little thing that he hacks on. An engineer see how that thing fits into the world and people who uses it. See the forest that your little tree grows in.
All companies and industries have standards, habits and a culture that it uses and the people are almost always NOT used to or interested in the little details that fascinate a hacker.The people out there will not change their entire culture to fit your hacking needs. The job of any technology and the engineers that build it is to facilitate the and simplify the lives of other people.
Professionality means that you take responsibility for your work. That includes taking responsibility for the interface to the users.
Read this:
The Clean Coder: A Code of Conduct for Professional Programmers (http://my.safaribooksonline.com/book/programming/9780132542913)
Number two: You cannot know everything. Accept it.
There is nothing wrong with expanding your horizons and going past your field, but when you are in a terrain where you are uncomfortable make sure your peers know it and make sure you have a mentor and listen to him. Or delegate to an expert. People will have a much higher esteem for you professionally if you have the balls to say "I don't know" instead of lying. It can be hard sometimes, but it beats being known as an arrogant little know-it-all.
Point number three: Education, education, education. Always assume you know nothing. Read up about your industry outside of the computer part. Computers are just a tool to make the gears turn. You will be a much better engineer if you know what the gears look like.
Good luck. You already took the first step and you will make it.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
Also read The Clean Coder: A Code of Conduct for Professional Programmers
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
I hope that helps!
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.
If you're good at something, enough that someone will pay you to do it, then go for it.
We need some people with the "hacker" mentality, they're like the blueberries in a blueberry muffin. Sure, you can make a muffin without them, but it's just not going to be as good.
It's all about time and experience.
As long as you know that growth is possible, and worth striving for, and keep that as part of your outlook, the maturity will take care of itself.
Check your premises.
"When you see a good move, look for a better one."
The most important thing I've learned over the years about being a software engineer is not to rush off and implement the first solution that pops into my head. Often, the hacker mentality is just to crank out a sufficient solution, so that you can pop your stack and get back to whatever it was you were trying to do in the first place. But as an engineer the best thing you can do in that situation is STOP and THINK. Don't let yourself write a line of code until you've had time to fall out of love with your original idea. If your first solution turns out to have been the best one, so be it; you've just wasted an hour. But it's far more likely that the improved solution you get as a result of the investment of that hour will pay your back 10- or 100-fold down the road.
Even if you're the only one developing, you'll want someone else to try it out, shake it and see if bugs fall out. Usually it's more than just you developing it, and other people testing, and other people managing. Getting along with others is the main thing involved with a professional's life as compared to the lone hacker mentality, I have found.
First off, a rant. Either your Computer Science program/dept does not truly deserve the name or you did not fully attempt to master the curriculum as it is intended. I know it sounds harsh, I am mostly annoyed by the constant misconceptions about CS that pop up here on /. from time to time.
A masters degree in Computer Science builds upon the basics of theoretical CS (theory of computation, languages, grammar, logics, discrete math...), technical CS (microcontroller, assembly) and applied CS (functional, OO and logic programming) from a undergraduate CS degree and extends it with topics about Networks (Sockets, Protocols, OSI Layers, Routing), AI (both classical AI with logic, planning and formal systems as well as machine learning), Operating Systems (for instance reimplementing parts of and studying Tannebaums Minix, Filesystems), Databases (Tuple relational calculus, OO databases, inductive databases, knowledge discovery) and also, and this is what I think you definitely missed out on, Software Engineering. This would involve developement models (V-model, Waterfall, extreme programming), UML, testing, maybe software verification, refactoring and so on.
Note that there is not much hacking (in a positive or negative sense) involved here. Great hackers do not necessarily need to be computer scientists, and competent computer scientists definitely do not need to be or leave the university as any from of hackers (be it some low level C pointer wizards or some OS file system experts).
I think what you meant to say is that the university did not teach you how to code in an industrial/enterprise setting. And rightfully so, thats the job of a vocational/trade instituion, but not of an university.
However, let me give you some pointers that helped me to grasp a bit more beyond purely academic programming.
1. Patterns. As some others have pointed out, this pretty much a must to grok in any OO project. The Gamma book is good, if you are looking for some really good intermediate more applied Java book about this, Effective Java by Joshua Bloch (he developed, among other things, the Java Collections).
2. Revision control management. One word: git. Anything beyond toy problems should not be touched without revision control. Watch the video with Linus Torvalds (the creator) to get motivated: http://www.youtube.com/watch?v=4XpnKHJAok8
A pretty good git tutorial that I like can be found here: http://www-cs-students.stanford.edu/~blynn/gitmagic/ch01.html
3. Read competent peoples code of the language of your choice! github and gitorious are a real treasure. The more you do it, the more you will discover more efficient approaches of how to implement certain concepts. And you will also see a lot of bad code and learn how to spot it.
4. Testing. JUnit is pretty basic to grasp. Some people swear by TDD (test driven development, write the test case first and then the implementation of what to test), I find this a bit extreme, however unit testing is a must to know.
5. Program yourself! Pair programming can be very helpful if your mentor is knowledgable and able to teach, otherwise do it yourself. Do not hack for the hell of it (although it can be fun), but focus instead on clean and clear concepts that you want to implement and improve upon. And document your code (doxygen or javadoc are your friends).
Don't worry. The field is not mature either.
One of the most eye-opening things I've read is On the cruelty of really teaching computer science by Edsger Dijkstra, one of the old computer science greats. While I don't agree with every point, it's well worth reading, and he has some choice words about software engineering:
"A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter 'How to program if you cannot.'"
and you mimic him/her. How do they act during meetings? How do they write tech-specs, documentation? Look at their check-ins, how do they approach code? How deep can they dive into a discussion? Then ask yourself how do you act during meetings, how does your writing stack up, how would you would have written that, where does your knowledge end? Repeat.
There is something to be said about faking it until you make it. Great engineers (and I've seen several in my day) have found a way to balance--their time, customer requirements, dealing with management, and other engineers and combined it with deep knowledge. Little of what separates a decent engineer and a great one is know-how, though. What really separates them IMHO is their countenance when dealing with a massive, ambiguous problem, their delivery record and the trust that they've garnered from that, their effective use of time and their innate, almost magically ability to be aware of any trade-offs the team and organization may be making due to their deep understanding.
If you aren't around good engineers you probably won't be one.
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.
“Common sense is not so common.” — Voltaire
"Engineer": "Hacker" with enough scars.
We live, as we dream -- alone....
I'm not sure you're entirely on base, but you've got the right idea.
If OP wanted to take software engineering, he should have taken software engineering, not CS. They rely on much the same in basic skills but they are different things. A MSc in comp sci isn't supposed to be a programmer who's taken 10 extra courses. You're supposed to actually do, well, science. It is real work, it is the technical architect behind the system, the technical director who figures out what problems can be solved by the tech school staff, the person who develops a novel or efficient solution a problem quickly hacked together by someone who didn't really appreciate algorithm efficiency, that sort of thing. Being an IT guy is not CS. Being a professional scientist is about using a scientific process and knowledge kit to apply to a problem domain (computing in this case), so error and failure rates, efficient algorithm that sort of thing. Efficient algorithms and representations of data is a big area of CS since it sort of encompasses languages (is it easier or harder to efficiently implement an algorithm in a particular language, why?), the tradeoffs etc. You're an expert in what data is, and what you can do it, whereas a software engineer is an expert in how to use a computer to solve a problem with data. If you trained in one expect a period of retraining to do the other, they aren't mutually exclusive but the are separate and somewhat complimentary.
I teach both SE and CS students. Because there is a LOT of overlap, and you can learn in CS SE skills, but the emphasis on the typically individual responsibility of a scientist vs the collective responsibility of an engineering project aren't the same. If you get a job it's up to them to teach you the area you are deficient in, SE's are usually good at designing a system and hacking it together to work, CS is there to make it efficient or to figure out how to solve a novel problem even if they aren't the one implementing it, or figure out what problem is even solvable (whereas the SE is concerned with whether or not the solution is implementable).
I realize the US is casual with the use of language here. But if you're a scientist you're not an engineer. If you have an MA you aren't an engineer. If you have an MBA you aren't an engineer. You can become an engineer with training after the fact, but if you wanted to be an engineer you should have been an engineer.
I wouldn't consider 'open source' as work in the same way as real work is. Volunteering to help build a house uses a lot of skills like being paid to build a house. But the 'on time, on budget, with the co-workers we choose for you, not the ones we want, on the hours we tell you' is a a different environment. If you can get an MSc in comp sci you don't need to 'work' experience of open source particularly (nor would you necessarily want to give the impression you're willing to work for free).
And you see old code everywhere. Academia is full of it, because someone wrote code to solve a similar problem to this 10 years ago, and you're using it now and it's been 'maintained' by 5 other grad students who've all long since left, and you're stuck with it now. Industry is full of it 'because it works', and government is full of it because they can't get money to put in something new even if they want to, or they put money into a politicians pet project that had nothing to do with the requirements of the actual problem.
Engineering a house:
1. Gather requirements
2. Write a spec
2a. make a prototype because users can't vision the spec the way you can, try nailing planks together to understand problem better.
2b. Did they like it? No? Go back to 1.
3. Design house to new spec based on plank prototype feedback.
4. Build house to design
4a. Realize that you didn't fully capture the problem because this is designing something *new* after all, not a simple assembly of a standard house, more like designing a new type of house each time.
4b. Get feedback, fix problems short-term by nailing planks together.
4d. Go back to 1 for the next version, remember to take some planks with you, you'll need them, it's not a perfect world.
You've got three broad brush categories, though of course people are often some of each.
- Programmers code stuff. Whatever you tell them to. Sometimes you can give them a problem and they come up with a solution, but it doesn't keep the entire ecosystem in mind. Often don't understand what they're really doing. Drives me batty when they're called Software Engineers. /product/, even if only an internal product.
- Hackers solve problems using whatever means necessary, however ugly it is.
- Engineers are solving problems keeping all the tradeoffs in mind and considering that this is a
Here's an example: This week a customer asked me for a feature in some PC software that generates files for processing by the embedded system. I know the entire ecosystem, not just the PC part of it, so I was able to tell them it was doable, but would have these negative effects - I can get you something working in the short term with these negative side effects, but we can get rid of them in the long run if we do this and that. They thought it was more important just to have the feature in the short term to show off in the short term and would ask me to make the other changes later if the tradeoffs got onerous. Maybe they'll never need it. This was a good deal for them in terms of what was delivered for what they're paying for my time.
You mention testing, but that's not really engineering per se, just one of the tools in the belt. A good programmer would (and should) be able to employ testing where necessary. In this case I did only cursory testing because they needed it /right now/ and the demo files I provided worked and were sufficient to show off the feature. And of course I told them this. Now that there's some breathing room I'll add better testing, and more if they decide to move forward on it.
It's all about knowing your /entire/ system enough that you can weigh the risks and requirements properly. Sometimes we blow a risk assessment or the requirement is wrong or something else goes wrong (customers are often very bad at providing real requirements or information) but at least you started from an educated guess.
You're a hacker, that's a good start since you're focused on solving the problem, and that's crucial - programmers are often (though certainly not all) bad at that. You are almost certainly more creative than some engineers. But now you need to consider that the requirements and the environment may substantially change how you choose to solve the problem. That thing you did may work, but is it maintainable and sustainable, and will it survive foreseeable new requirements?
Another example: there's a place in one of our codebases where sometimes you're looking for a string in an array in user time (someone typed something). We don't bother to sort that. Who cares? It's 'instantaneous' for the user either way. Why waste the time and code and complexity sorting it? There's another case where we're constantly looking things up, on the order of 5x a millisecond, so that one is sorted. But not cached since 5x/msec isn't /that/ much of a hit in context
I went a bit long, but I hope this makes sense. It's all mindset. Engineering is learning everything you can that even indirectly effects your system and solving problems based on ALL the tradeoffs. Realistically you can't know them all, but you can try. Iteration helps, as does time and budget.
To "code something up (using a lot of prints to debug)" means hacking, i.e. rigging software together with the emphasis of doing it as quickly as the intuition allows, at the expense of readability, reusability, reliability and ease of change.
Agile software development, in a nutshell, means acknowledging the fact that noone can really know what true final requirements for the eventual finished product are, so the idea is to start small and simple with a small feature set and gradually evolve into what the customer really wanted in the way of iterations - but at all times keeping the code tested, clean, readable, reusable and version controlled. It's about always having working version of the software, whose expected functionality can be demonstrated and verified with automatic tests, while using them to constantly refactor the code to better and clearer. It's about keeping the cost of changing the software low, while on the other hand, the cost of changing quickly hacked-together applications increases exponentially with complexity.
only a problem for software you pay good money for
with proprietary closed source software, users pay to become beta testers because not only are there less eyes on the source compared to the FOSS model, but closed source projects are run on unrealistic timelines and budgets. software companies make software to maximize profit, not to produce bug-free product. they do enough debugging to minimize complaints to a point where they can maintain their reputability, but no more. once the release date is reached, the product moves from development to sales, and the development team moves onto the next product.
FOSS is often a step behind, but that is because there is no such pressure to achieve marketing deadlines or breakeven, because there is no profit, but this also means that the programmers are free to take as long as they like to debug the software to their own satisfaction, and like any art or skill, programmers can be their own worst critics, particularly if they are developing software they wish to use themselves
I don't think I've ever come across an actual bug in a FOSS application because I stick with Debian Stable mostly (sometimes Testing), but even if a program misbehaved, I would be disappointed but given I paid nothing for it, I can't really complain that much. On the other hand, if I pay for a Windows game (Sim City 4 for example) and it crashes regularly on a newish machine and web searches don't reveal an answer (and the vendor's website is a useless piece of shit), I'm going to be pissed off for wasting my money.
In response to the OP, I don't have a CS degree but I develop software in my job (engineering), as well as at home. I must admit I've never debugged on paper before (is that what you meant by "prints"?). I usually just get a feature to a stage where I think it should work, and then I compile/test the crap out of it, finding/fixing bugs as I go. Its much more fun and practical than looking for bugs that might not exist on paper. Maybe its just because I'm not that old, but I couldn't even imagine debugging on paper.
I wouldn't call it "hacking" though. I think its actually called "extreme programming" or "agile software development".
http://en.wikipedia.org/wiki/Extreme_programming
Income and paperwork.
After logging in slashdot still does not take you back to the page you were on. It's been that way for 20 years.
The most important difference between 'hacking' and engineering is understanding time, and understanding humans (epsecially yourself).
In a nutshell:
0) learn the difference between 'clever' and 'smart', and then 'smart' and 'wise'.
1) code is to your employer as mass is to an aircraft engineer: less is better.
2) understand how and when to say "no" to your management, or more realistically "how long" and "what it takes" and don't overestimate your total productivity in delivering product as opposed to a caffeine-fueled hacking.
Don't sweat it. You'll be doing fine. It's commendable that you want to be better but yes, the "piece it together and keep compiling and building 'til it does kinda what it's supposed to do" is pretty much the approach (too) many programmers have to a problem. It's not your problem. It's an industry problem.
One thing university hardly prepares you for is the reality of programming. You won't start fresh with a project, at least your chances to do that are slim to nil. You will most likely be hired in the middle of a project, or at the very least you'll have to deal with existing code that somehow affects whatever you'll be writing, code that grew with time, was patched, fixed and altered a hundred times and looks it. Meaning, it will be a mix of various coding styles, parts that nobody really knows anymore what they do or how they do it (because whoever wrote and maintained it is no longer with the company), with hardly documented features and even less documented side effects.
This is what you'll encounter in your job. In other words, the "hacker" approach is most likely exactly what will allow you to survive in there. It's the unfortunate reality that code is more often than not in a rather bad shape and few people are "true programmers". Hell, you have a CS degree? Congrats, chances are you're already miles closer to being a programmer than most people working there...
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Tight algorithms are nice to have for most of the people actually using software. Engineering is an applied science. Engineers solve real problems which means clearly identifying the potential for their investment.
Identify who is going to use the software. Who is this person? Put together a profile on a couple sheets of paper. Have a face for this person. There may be a few personas that will use the software.
Given these personas. How do they accomplish the task you intend to improve today? What is painful in their current workflow? A possible answer is they can't do it.
Given these pain points. Create a list of pain points you can address. When you can say how these will be addressed, they become a functional specification. Part of the functional specification may include performance related concerns if it is driven by the persona.
Given a functional specification, you will need some architectural design to make the implementation possible, document that.
Now you have enough to say how you will test it; some will be unit tests and some will be operational. As you document the testing, you may find your functional specification needs to be more precise.
From there, use what you already know. Improve upon how you implement as time permits but keep the larger picture in mind.
Ideally you will have others review your documentation and code before letting it out the door.
When you are done, everything goes back to the original persona with pain points you are improving. If the tests are passing and the end user is not satisfied, you missed a requirement in your functional specification.
"with proprietary closed source software [...] compared to the FOSS model"
I think you are mistaking possibilities with realities. Yes, open source has the *potential* to more eyeballs but then, all so much FOSS projects have are the two eyeballs from its only developer. Yes, FOSS has the potential to get rid of absurd timelines but then you see so many projects that deliver on a deadline, ready or not ready, or answer you about a bug report with a variant of "I don't have time to deal with old bugs, I prefer to expend my time on more bug-ridden features". Yes FOSS is not necesarily driven by maximizing profit, but they aren't necesarily driven by its quality (i.e.: they can be driven by it fun factor).
"because there is no profit"
Who told you that? That's obviouosly false. They can and certainly are for profit in a lot of situations, it's only that their revenue stream is not on selling use licenses but in the development fact itself (features on demand; I worked for a company like that -the problem is when this becomes a freemium model where known to be necessary features are not developed unless something pay for them) or in installation and support (and then it can be possible that never good install procedures or documentation will ever be produce).
"I wouldn't call it "hacking" though. I think its actually called "extreme programming" or "agile software development". "
But then antifoidulus is right: hacking something together and pushing it into production is, well, hacking and certainly has nothing to do per se with extreme or agile programming. Your approach can lead to a good solution (if the problem realm is not so difficult and you are good at it) as well as to a fast pile of shit that only worses as time and feature crap goes by. As such is the opposite to engineering, which is about insure the results.
This seems a little unfair.
I didn't spent years of my life studying "to put food on the table" - I studied and became an engineer because of my passion for technology. In other words, I love my Job and I love developing software.
The "so called" engineer would actually know that methodology and testing not only doesn't have nothing to do with engineering, but instead knows that these are (some of many) tools with which to produce quality solutions.
The problem is that managers want a shoe box, engineers design a shoe box and hackers then sit there and ponder how to fit a TV into it when the manager changed his mind.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
So it would help to know what your new job is. Blue-sky research? Existing install base (aka maintenance)? New product development?
How about target space: mobile? embedded? cloudy? big data?
(Tool sets & technology stacks don't matter so much, you'll find those are the easiest part to wrap your head around.)
In any event, congratulations & good luck!
I pride myself on being an engineer. And I absolutely love my work.
I coded professionally for years before I got my degree. But it took time, and a certain amount of formal training, to truly mature into an engineer.
These days, I play with some pretty big toys. And there most certainly is a part of me that's still a hacker. But that part is very much directed and disciplined by the engineer part of me.
As a result, I still get the joy of building things - at the code level, and at the architect level. The discipline allows me to build great things, not just toy projects, which is all that the undirected, undisciplined hacker will ever build.
Because I'm willing to learn (to read those manuals, and pay my dues), I've worked on everything from embedded to massive distributed systems.
Being an engineer and a hacker don't have to be mutually exclusive. Perhaps not all engineers have the drive and passion to be a hacker; perhaps not all hackers have what it takes to acquire the discipline of being an engineer. But those who can be both get to play with the biggest toys, get to work on the neatest problems, and, honestly, make the most money at the end of the day.
Check your premises.
An "engineer" is somebody who takes the time to understand a problem, and creates something to solve that.
In an ideal world, you bet, the above is true.
But we live in the real world, and in THIS real world that we live in, there are simply too many people who call themselves "engineer" who never take any time to understand any problem
The many years I've lived in this real world tells me that I don't want to be known as an "Engineer" even when I am more qualified than 99.99% of those so-called "engineers" out there
Muchas Gracias, Señor Edward Snowden !
Software engineering is more than just coding and testing. It about getting exact requirements from the client; documentation and boring paperwork (always more paperwork!), collaboration, time management...
You could say software engineering is coding with the fun taken out of it. My advice: try to get a in house job in a tech firm, where the 'client' are technical people who know what they need, and to whom interesting problems and clever algorithms matter. That way you'll spend more time coding and less time on paperwork and moving buttons in a user interface.
assignment != equality != identity
That's why you have the manager sign off on the requirements and functional specification. He can change his mind (and often does as a company better understands the market) but the cost is then his responsibility which he can balance with the potential reward in his decision and communicate a justification to stake holders. If you just make the box, the responsibility is then fairly yours. How was the manager to know the cost of his decision?
If you fix every problem with printf debugging you are likely to waste a lot of time when you are solving problems that are easy to solve in IDE debuggers. Sure, I still fall back to printf debugging when its the best tool for the job and sometimes its really the only tool for the job but its only one tool.
Really the best advice might be to understand how to use tools. I don't mean go out and learn every tool you can, or master one IDE and source control system. I mean try to understand how IDEs and debuggers work in general along with source control, build systems, test systems and analysis tools. Obviously you want to become proficient with your toolset but understanding how you might manage source control branches to manage a release or what kind of analysis tool you might use to find a performance problem or a memory leak.
I think the best advice is to work at a place where a decent number of people understand these things and learn from them but finding such a place can be difficult especially when you are inexperienced.
"In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson
Go with it, just like the guys that call themselves Architects, Gurus, Batman or whatever, just don't try to pretend like some of the others above that it makes you equivalent to a professional engineer.
I'm not an engineer. I used to be an engineer. I've worked in power stations, oil refineries, offices etc and helped educate engineering students at a university and been a member of IEAust and ASTM. However, due to a lack of jobs a bit over a decade ago and a career change now that I run the computer systems for a company and write a bit of code every now and again I'm not an engineer anymore. You can call yourself whatever you like and are perfectly justifed to use the title given to you but don't expect everyone to take it seriously, especially since professional engineers have a code of ethics that you do not have to stick to.
Your view of what a SW engineer does is sadly overly idealized. I've been at the profession for 20+ years and have at best only sporadically glimpsed the world you describe. I wish that there was more actual methodical engineering involved, but most projects very quickly jump to the "we just need to get sh*t done" mode. The skills you describe somewhat negatively as "hacking" would serve you quite well in many or maybe even most shops.
I'm still a "hacker" 25 years after getting my first computer, studying data processing and computer science, and writing and maintaining software. I never cared for the term "software engineer." Back when I started, "hacker" wasn't a bad word. A good "hack" meant a great prank, or a really cool or elegant solution to a difficult programming problem. It was also used by hardware folks, since most of us could take our computers apart and put them back together ourselves.
Professionally I have always used the word "programmer.". People in IT and management both respect the word, and you don't sound like you are trying to make yourself some titled position, like "sanitation engineer" instead of "garbage man."
Nitewing '98
Everything works...in theory.
I think you are mistaking possibilities with realities
You're right, but there are for example lots and lots of eyeballs on the Linux kernel source. Also, at least FOSS has this possibility (and while not always being reality, it is sometimes).
Yes there can be profit in FOSS, but its not usually from the software itself (by definition "free" as in usually both "free beer" and "freedom"). Profit for companies dealing with FOSS is usually from selling boxed versions of the software, documentation or support contracts. The "features on demand" that you mentioned, if sold for profit, aren't really FOSS are they (even if the underlying application is FOSS).
Hacking has evolved beyond the original "tinkering" definition of yesteryear. It's now associated with unauthorized access.
From http://www.extremeprogramming.org/ "instead of delivering everything you could possibly want on some date far in the future [extreme programming] delivers the software you need as you need it". "Hacking something together and pushing it into production" might not adhere to all the rules of extreme programming, but I think it fits the extreme programming model well enough, particularly for in-house development where the customer and the developer both work within the same company.
As such is the opposite to engineering, which is about insure the results.
As long as any software produces the correct result, how it achieves it is usually of secondary importance. Many people with CS degrees focus too much on the "how".
He means running it and seeing what happens by adding lots of System.out.println();s or whatever the language of choice equivalent is instead of using a debugger. Well, I assume that's what he means.
You're right, but there are for example lots and lots of eyeballs on the Linux kernel source. Also, at least FOSS has this possibility (and while not always being reality, it is sometimes).
Where I work, there is the nice principle that for every bit of work there have been at least four eyeballs seeing it, and probably more. Guaranteed. Not just a possibility.
We can also use a mathematical argument: What is the total time that people spend reviewing FOSS code? What happens when code is so badly written that you can't effectively review it (with my code, that would just make it unaccetable).
Believing something doesn't make it true. Not believing something doesn't make it false.
CS teaches you how to build something that works correctly. CS doesn't have much to say when things don't work as expected.
If you can't debug, really, really well, then you can't be an engineer. That your own programs won't work right (and you can't fix them) is only part of it; Debugging causes you to learn what does or does not work in the real world, ivory tower CS solution be dammed. With that knowledge and understanding, you'll better engineer your next program taking that into account.
My
...not the use of the waterfall model.
This is *not* controversial! Look up the term "engineering" in a dictionary or Wikipedia if you don't believe me.
For some reason, a lot of people have the mindset that engineers have to do everything as per the waterfall model, and that software engineering is all about process, methodology and code maintainability. This sort of thinking is really just cargo cult engineering.
Other branches of engineering often do things in a waterfall-like process. For example, a bridge has to be designed before it can be constructed; you can't build a bridge incrementally, and construction takes a long time. But there's no such requirement for software. Software can be developed incrementally, and compilation is very quick compared to construction/manufacturing.
There are other engineering fields where things are engineered incrementally. As an example, take a look at how an F1 car evolves over a season. You'd have to be crazy to claim that the people who design F1 cars are not automotive engineers because they don't do waterfall.
What separates software engineers from hackers is that software engineers analyze the systems they work on, using computer science and mathematics. They reason about performance and computational complexity, they reason statistically about reliability and fault-tolerance, or they use mathematical models of real-time systems to schedule real-time tasks.
They don't spend all of their time writing documents and talking about maintainability.
Documentation, maintainability and process are all important things, but they're not the defining traits of an engineer. What makes an engineer an engineer is their application of science to solve a problem.
If you want to make the transition from a hacker to an engineer, learn the maths and computer science that underpins the software that you'll be working on. Not all software needs to be engineered; a lot of internal corporate web apps don't need to be engineered, but sites like Amazon, Facebook and Google do. A lot of real-time and embedded software needs to be developed by software engineers too. If you want to be a software engineer, make sure you go to work at an engineering firm.
Or don't. There's nothing wrong with being a hacker. Just make sure you don't become a cargo cult engineer.
What is the total time that people spend reviewing FOSS code?
probably nobody knows the answer to that question (I don't see any mathematics in it though), but I would guess that a lot more people have reviewed various aspects of the Linux kernel source than Windows kernel source, even solely from the point of view that Linux used in any critical task would probably require at least some review by any organization relying it (probably including NASA, DoD, Google, Red Hat, IBM, etc). Even aspects like competition with Windows and the controversy surrounding patents and copyright violation in the Linux kernel would have attracted eyeballs, with Microsoft most likely looking for bugs and exploits to use in smear campaigns. Then there is the embedded market, with set top box manufacturers likely having a squiz at aspects that affected the functionality of their hardware. The Linux kernel is probably the crowning achievement of the FOSS community because despite being free, it is worth so much to many organizations that depend on it that the many scrutinizing eyeballs on the Linux kernel are probably less interested in the kernel as a product itself, but as something that will cause significant grief (financial and otherwise) if it fails. Windows on the other hand presents a risk to any organization who selects it for a mission critical app because they can't inspect the source code and the organization has no control over it (whereas if a bug was found in the Linux kernel, its possible that an in-house patch could be "hacked" together to get things moving again.
What happens when code is so badly written that you can't effectively review it
When you can't review it, you test it, but I would never personally use code I couldn't understand. If it was the only code I could find that did what I wanted, I would probably spend the time reinventing the wheel. Having said that, if the code worked and was accessible, even if poorly presented you should still be able to read it. I would argue that the likelihood of there being code that couldn't be reviewed at all would be pretty slim (its just text). Even if I had to use one of those programs that improves presentation (puts line breaks after non-string semicolons or after "then" in the case of Pascal/Delphi etc), or I could roll my own if I didn't like any on the net. Poorly written code also probably wouldn't last long in a public FOSS project (sourceforge, github, google code, etc) in a team of programmers who actually gave a crap.
FOSS programmers review FOSS code, because it can improve their skills or can be used in their program (GPL code can be reused in other GPL projects), and there are a lot of FOSS programmers out there (look at the Debian package repository for example).
1. Understand the users and businesses who are going to use your product, and what they need from you to be successful. (And create a minimum no. of support requests later on). Spend actaul time doing it. No, really!
2. Understand that testing is needed to uncover all flaws in your program. Learn to appreciate the good testers, who do anything to break your code. Again, it will help minimize the shit storm, when you release (flawed) code to production.
3. *Then*, you can start honing your hacker skills, selecting the algorithm that will squeeze out the last 2% real world speed increase.
The most successful engineers I have met as a project mgr/product owner master the 3 above.
Don't take it from me, look up the website for any professional engineering body and see what the requirements are to join.
Nice little joke but I'm trying to be serious here.
Fair enough, but "I could have been a contender" does not equal champion even if the rules are skewed to unfairly keep you out of the ring.
>nobody in the 'real world' is any different
And the public wonders why most software is bug-ridden, badly designed shite.
Insightful? Really? This is exactly the opposite of Insightful.
The difference between Science and Engineering is perfectly illustrated here. Computer Science is NOT Software Engineering! Engineering is applying theory and high-level ideas in the real world nitty-gritty land of bullshit where nothing really ever works 100% how it theoretically does, and you have to make seemingly impossible solutions "just work right now, goddammit!".
To the submitter- sounds like you're already on the right track. "Hacking" (I see you're using the old definition, not the modern one) is exactly the skillset you need to be an Engineer. CS is helpful to software engineering, as it provides a good foundation of understanding, and gives you the knowledge of how things ought to work. But as for how to actually approach a real-world Engineering situation, CS isn't going to provide you with much at all in the way of the skills you'll need to design, deploy, troubleshoot, and implement Management's twisted desires.
Being a good hacker is fine, but acting like a cowboy (someone who is reckless or irresponsible) when putting code in to production isn't.
Creating quick and dirty solutions can give you great insights, implementing them that way in production environments will bite you in the ass later on.
A hacker gets things done. An engineer enumerates the pros and cons of various solutions and picks one.
The work you do will rarely be complicated or sexy, in the CS/theoretical sense. But it will be put up against a lot of non-technical forces like time, budget, politics, etc. Being an engineer is about navigating this imperfect space. A hacker will come up with one solution, but an engineer will come up with many.
You're multiplying the solution space by a certain amount of non-technical dimensions and accounting for the difference. That ability will come in time. You will find out that technical correctness isn't always the #1 priority.
I take a problem, sketch together a rough solution using the appropriate CS algorithms, and then code something up (using a lot of prints to debug). I do some basic testing and then go with it
That is exactly how we, "engineers", often do it.
How do you get out of the 'hacker' mindset?
You don't. The "hacker mindset" is precious. Never lose it. Illustration: not earlier than yesterday I presented a Proof of Concept to a client. The guys were thrilled. Basically, all I had done was hacking an IBM tool, to make it do something it does, out-of-the-box, badly. Don't change, dude !
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
Actually, university education is very detached from working in the real world. Most teachers want to make a researcher out of you, not an engineer.
After your graduation you need at least six months or a year of real life work to learn to put the education to real use. You should be happy that you alread are a talented hacker, so you can be productive from the start.
With the time you will recognize problems coming up in your day to day job, that you learned about in university.
Of course not since I know nothing about you and it's a conversation not a silly personal attack. I put it in the title because that's just another bunch of people using the title that somebody else (Microsoft) gave to them. It's an extreme that everybody knows even if it's not as bad as it used to be, just like the guys that run cables that get called "engineers" by their employers and then that title gets shoved down the throat of customers.
As I said above, my opinion is to go with it, just don't expect everyone to take it any more seriously than "Guru" and don't get suprised when people occasionally look down on you for adopting a title they think you don't deserve. Most of the time that's their problem. It's my problem when somebody at an simple course certificate level and no experience uses it as a bluff and pretend some sort of ability they do not have. That pisses me off so much that I react every time the "why can't I call myself an engineer" question comes up even if somebody is a the point where they are effectively working as one anyway.
Anyway, IMHO it's a matter of convincing a professional body of people with that title that you deserve the title (eg. real Architects have to jump through a lot of hoops before they are recognised as such), otherwise it's as meaningless as calling yourself Emperor.
There are different ways to become an engineer. First, the hard way. You code somthing up and then you aren't able to maintain it sufficiently. In the end you have to rewrite. When you do that cycle often enough or have seen rotten code of others often enough, then you should normally be able to make the transition. The first thing you can focus on at that point are methods and procedures. All that shit that hackers call a limit to their freedom. Today agile approaches are very popular, but they require a lot of discipline and they are merely improved old methods. The old method to learn is V-model or RUP or even the old "requirements -> design -> detailed design -> code"-method. For agile methods you have to learn that you have to iterate these processes and that you always start with a requirement cutting it into pieces called features and then add something to you design.
Second, you could have it easy and start reading and implementing engineering methods in your job. In this version you just believe that it hurts not to do so, which leads normally to less motivation.
But the main lesson is, learn and use the methods of software engineering. With time you will learn to use them wisely. And yes you should have heard software engineering classes in grad school, but you can still learn all that stuff. The big picture is not too complicated. Complicated things arise on the road.
For some reason, a lot of people have the mindset that engineers have to do everything as per the waterfall model, and that software engineering is all about process, methodology and code maintainability.
I think this is because the traditional methodology (or should I say Methodology) cult has branded itself that way for a very long time. I had a CS course on software engineering with a 800+ page "software engineering" book full of intricate ways of producing tonnes of almost completely useless documents and very little real-world advice on how to actually design and develop software and manage a software project.
What separates software engineers from hackers is that software engineers analyze the systems they work on, using computer science and mathematics.
And thinking critically about new ideas and their application. There are lots of fads and architecture astronauts in software development.
I wouldn't call it "hacking" though. I think its actually called "extreme programming" or "agile software development".
See, it's not just PHBs who can play buzzword bingo.
To have a right to do a thing is not at all the same as to be right in doing it
There are plenty of people who are paid to do it that wouldn't be classified by any sane person as engineers, so that's pissed all over your invented distinction right there.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I'm a software developer by trade, and I'm also old enough to be of the generation where one has pride in one's work but, in my experience, many places where I've worked don't seem to share that same pride in a job well done. Most care far more about getting something, no matter how "bug-ridden" or "badly designed" out of the door so they can bill the customer.
I always remember this quotation from the great Niklaus Wirth:
In a well known interview with Dr. Carlo Pescio, published in Software Development, June 1997, Pescio asks Wirth:
You probably know about the 'good enough software' concept popularized by Yourdon. In many senses, it's just a rationalization of what's happening in the software world: the first company hitting the market with a feature-rich product is more likely to win the battle than the careful, quality-seeking company. Do you think there is anything developers and software organizations can do about that? I guess many developers would be happy to be given more time to develop better software, but at the same time they are rushed in the name of corporate survival. 'Educating the users' seems more a wild dream than a possibility.
to which Wirth replies:
'Good enough software' is rarely good enough. It is a sad manifestation of the spirit of modern times, in which an individual's pride in his/her work has become rare. The idea that one might derive satisfaction from his or her successful work, because that work is ingenious, beautiful, or just pleasing, has become ridiculed. Nothing but economic success and monetary reward is acceptable. Hence our occupations have become mere jobs. But quality of work can be expected only through personal satisfaction, dedication and enjoyment. In our profession, precision and perfection are not a dispensable luxury, but a simple necessity.
Write it, fix it, learn what you did wrong, lather, rinse, repeat. It's how ALL of us gain proficiency.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
I'm not sure if masters level is any different but the undergraduate program I was in there was only a 2 elective difference between CS and SE. I took all the electives for fun. When I graduated they asked did I want to have CS or SE on my degree. I said why not both. They said I only paid for one degree. I still don't remember which one I am.
I love Jesus, except for his foreign policy.
Those are two major factors I haven't seen while skimming comments.
Most of your communication is done through keeping in touch with your peers. Talk to them, understand what they're doing, etc. But also long term, document your code as you go, either with written documentation or, better, with tests. Especially, learn what they're doing right, and tell them; people need recognition from their peers.
Professionalism is pretty easy: learn how to use version control and continuous integration, e.g. Jenkins. Use CI, especially, to make sure that you fix your bugs right away. If you set it up and use it rigorously, you'll find you can put out some very high quality code, even though it will be at a slower pace than you're used to. But for large projects, fixing bugs "later" is madness.
the really productive and happy software engineer is the one who can hack something together, or be meticulous and pedantic, when the job calls for it. the key is knowing which approach is the best route for the project. there can be elegance, simplicity and organization in both.
Join the Slashcott! Feb 10 thru Feb 17!
Yep, with most of the big engineering firms I've worked for, it's maybe 5% hacking and 95% documentation and packaging. If you can enjoy doing mostly the latter (finishing the last 10% of a project that ends up taking 90% of the time), then you should be able to get along fine. If you spend all of your time doing the former, then you will quickly become reviled by your co-workers :-P
Here's the junk that seemed important to engineering companies:
So, in summary, if you can find your way around some sort of toolchain that involves doxygen, mercurial, make/ant, cobbler, jenkins, and redmine, to the point that you can hand a junior engineering a piece of paper (oops, I meant email a link to a desktop instruction) such that the junior engineer can build their own working copy of the product by themselves with nothing but cold iron and a revision tag, then you're doing well.
But really, the real trick is to figure out how to get everyone on the project team to use the same toolchain :-P
All the other things, like whether to use a revision control system, an IDE, particular technology etc. are constraints provided by your environment or chosen based on intermediate results of your "research".
"I love my job, but I hate talking to people like you" (Freddie Mercury)
And the reason it
s poorly made is the hacker mentality.
Just 'write code and it works' and it is done. The industry must mature past that and move on to actually engineering. The software industry must become an industry of excellence.
The Kruger Dunning explains most post on
You're an idiot. I pity the people that need to go around and clean up your crap.
The Kruger Dunning explains most post on
First and foremost, self-discipline. Yes, I know, it is hard.
Be prepared to go unrewarded for your "extra efforts" which are in actuality basic software engineering tenets.
Do NOT design at the keyboard. You can be agile without designing at the keyboard, you can be a traditional waterfaller without designing at the keyboard, you can be a spiralist without designing at the keyboard. When you find yourself making design decisions at the keyboard, unless they are truly trivial (and the litmus for this will change with experience) WALK AWAY from the keyboard.
Ensure that the people who assign you work understand the caveats of what they are currently asking you to do. Even if this makes people think you are being negative, give them the information they don't even realize they need to make better decisions. YOU are the expert on what will happen when implementation happens. For example, if your product manager or account manager or <insert PHP - pointy haired person - here> wants a milestone that includes features that are poorly defined (either through their own recalcitrance or through, most likely, a customer who doesn't know what they really want) it is your responsibility to be the a**hole negative nerd who makes it CRYSTAL CLEAR the implications of doing such a thing. That doesn't mean you don't do it, it means you sacrifice whatever small amount of political capital you have with them to ensure that everyone is on the same page about the potential outcomes. You're going to be shocked by what people can 'pretend' to not recall ;).
Think about problems in a fashion designed to allow for systemic flexibility because, just like in war, everything goes to plan until the first shot is fired.
Think about the long term viability and accessibility of the code you write (good variable names - really, I know you've heard it a thousand times probably, but it makes all the difference in the world.) When the choice comes down between 'clever' and 'clear', unless you have a really compelling reason to be 'clever' - go with 'clear.' The codebase isn't a place to show off your 'chops' - it is a place to think about all the people that will or may come into it behind you and they may be clueless or very inexperienced. Comment your code, another 'I have heard it a thousand times' one I know, but people just don't seem to do it because IT TAKES DISCIPLINE.
If you haven't done much with software patterns, pick up 2 or 3 books about them (both local and network patterns) because, although dry, they often contain the 'wisdom of the ages' for people new to software. Hell, just two weeks ago I was discussing a feature our Services team was implementing for a solution (I run Engineering, we produce products that the Services team [and external parties] uses to implement solutions) and they needed to simulate a physical machine. They were at a total loss about how to accomplish this (no snickering you experienced developers - especially game guys!) When I broached the topic of state machines they all went sort of glossy eyed (like some fish I'd just reeled up from 200 feet down.) After I explained for a few minutes I got a lot of head nodding. The next day I wrote up a little Java applet (yech) that demonstrated a crude approximation of the machine and used a state machine for managing it. Suddenly, everyone in Services is all about state machines (it is pretty funny actually - they have a shiny new hammer and they are wandering around looking for nails.)
There are dozens of things we could discuss but aside from the final thing I'll recommend below, remember, you don't want to just be a programmer (so it sounds) so to be a software engineer you need to have all the abilities of a programmer but also spend time thinking about the process, efficacy, flexibility, and extensibility of how you will implement solutions to problems.
The very last thing, and very important although many people who call themselves software engineers ignore it, is to be technol
Loading...
And I have always felt that when someone asks you what you do / what "are" you; it would be most correct to answer with what you get paid to do.
If you have a degree in EE, but your job position is "Programming Team Lead", you are a programmer, or possibly even a manager, but not really an engineer.
Conversely, if you never went to college but somehow manage to work your way into a full engineering position and you perform that work adequately, I would call you an engineer.
Of course, take that attitude to the extreme and If someone pays you on the street to give medical advice, can I call you a doctor? I think the answer is yes, you may be the worlds shittiest doctor but someone believes in you enough to pay for your services.
In some juristictions (eg. Ontario, Canada) the Professional Engineer's association takes you to court and collects a large fine from you if you call yourself an engineer and don't have a license from them: http://www.peo.on.ca/enforcement/callmeengineer.htm
So to "transition from hacker to engineer" with a Master's in Computer Science, you'd turn around, go back into university, and enroll in an undergrad Engineering course. The last time I looked (admittedly over a decade ago) the closest was "Computer Engineer" which did some software, but had rather more in common with Electrical Engineering than Computer Science.
Be aware of the legal status of the word "Engineer" in your juristiction before you add it to your title.
CS degrees will never be engineering degrees because too many CS people keep saying math is not important I know how to code already.
Because I'd like to recruit people from wherever you learned. The recognition that testing is appropriate, and that you have things to learn, is so rare among working systems personnel that your school and mentors should be congratulated.
If you can, talk to the QA people where you work about their processes. Don't simply take their word: have lunch with them, walk through it with them, and note where they deviate from the planned or published release process and why they skip or redo parts. (This is often political, which I'm afraid is part of testing.) And get involved in some GPL projects with test suites, to learn more about how they're structured.
If you want to be a Software Engineer??? There's little in common - a Computer Engineering degree would be more appropriate, and if you had "Electrical" in that degree title you'd have an even stronger engineering basis.
The first level of programming is hacker. Most of us started there. Basically you are screwing around and after a while your screwing around gets better and better until someone pays you. This is programming as art but this is still fingerpainting. People can get really really good screwing around but there is a limit. Often a master of level 1 might know PHP inside and out. The next level is where you are properly educated. Not necessarily a degree but you need to learn the core, assembly, some discrete math, etc. At this level you can start doing things like building VMs, your own compiler, use OpenGL, etc. Many people graduate from a university thinking they are already level 2 but even their fingerpainting sucks. Many people mistake UML, SCRUM, and other faddish things as level 2; wrong. Hard core math is a key piece in level 2. .... programming is much more than programming. It is project management, communications, database admin, server admin, graphic design, psychology, plus much more non coding stuff. One of the few certifications that will get you way ahead in programming, oddly enough, would be from the PMI (Project Management Institute).
Level 3 looks a huge amount like level 1 as you often go back to fingerpainting. The difference is that there is less time wasted screwing around. It is like one of those artists who walks up to the canvas and with 3 strokes give you Jimmy Hendrix.
So if you want to move past hacker the next thing to learn is real computer science.
But
^This
The fact that you take the time to actually design something sensible, and are willing to go through some debugging and personal testing pretty much puts you in the development/software engineering pack. The best thing to do is keep working at it, and if you really want to go through the "official seal" of software engineering, you'll need to address it through process.
Make sure the design documents are put together as living documents (maintained throughout the lifecycle). Get your versioning system in place. Make sure the testing team has awareness and a way to properly validate software quality, and that all possible code paths are covered in the testing process. But as far as you are concerned, you'll need to use what you've learned to either fit into the processes, improve them, or create a working process.
Here are some suggestions to becoming a proficient software engineer:
1. Learn to work your way up the capability maturity model (and help your company to do so). See item 6 in the following article.
Learn to avoid the "7 Habits of Highly Dysfunctional Developers". http://www.ganssle.com/articles/7habits.htm
2. Jack Ganssle's articles are great reading for programmers wanting to build reliable systems. They are helpful for both embedded programmers and people working on other platforms.
http://www.ganssle.com/articles.htm
3. Here is Jack's recommended reading list.
http://www.ganssle.com/bkreviews.htm
I have found his own books to be useful.
http://www.ganssle.com/book.htm
4. Jack's articles in Embedded Systems Programming magazine contain lots of programming wisdom.
http://www.eetimes.com/electronics-blogs/21/Break-Points?Ecosystem=embedded
"Anybody can design a bridge that is strong enough to carry the load.......what is difficult is designing a bridge that is JUST BARELY strong enough to carry the load!"
Read Code Complete. Then practice the principles outlined in it everyday on every project, and you will no longer be a hacker.
That's why you have the manager sign off on the requirements and functional specification. He can change his mind (and often does as a company better understands the market) but the cost is then his responsibility which he can balance with the potential reward in his decision and communicate a justification to stake holders. If you just make the box, the responsibility is then fairly yours. How was the manager to know the cost of his decision?
Also, try always trying to build a box with extendible sides. If the manager baulks at the cost of this then tall him the only way to save him money as that he cannot possible make the box larger later. Giving them a choice of solutions where the cheapest solution has clearly specified limitations is a good way of covering both angles. He can them make a cost / benefit choice.
I dont read
Ensure of insure?
It's a difficult transition, and one I had to make myself within the last year. There are really two major things that helped me to become a much better programmer, and got me out of the 'hack/patch' mindset. 1) My company has a mentoring relationship set up - I had the good fortune of working with a mentor that had the right mindset, and worked hard at it. Even if your company does not have such an opportunity, try to find someone at the company whose work is well respected, and see what you can learn from them (or failing at that, from their code itself, since there should be plenty of documented changes). 2) Take your time. There is always going to be multiple solutions to any given problem. What will set you apart is if you look at it, and cure the problem rather than the symptoms. When you see a bug report, don't take it at face value. Find out *why* the software is doing the sort of thing it's doing, and fix the right problem. The hardest part of it is actually finding the right problem. The easiest analogy is thinking of yourself as a doctor. If a patient has a bad cough, a bad doctor will give you some cough syrup and call it a day. A good doctor will find out why you have a bad cough - sometimes the solution is a cough syrup, sometimes it's a chest x-ray and chemo. But the doctor that gave you cough syrup, even if it did end up being nothing more than just a cough, really didn't do his homework, and is going to do plenty of harm in his career.
So I have my EMT-Basic, a course and certification that takes about 3 months to complete. I guess I'm a doctor, huh?
I agree, I am like the OP, hacker who got a master's in CS, and I code roughly the same, by intuition.
"Science will win because it works." - Stephen Hawking
Yes, but the public also expects timely releases. Large customers expect their own pet features and they expect them yesterday.
Guess what? With 30+ years of programming under my belt, that is exactly what my career entails.
"Software Engineering" is a misnomer. While there are certainly aspects of programming which can be canned and automated, the creation of GUIs, reports, understanding requirements, and coming up with the right algorithms to IMPLEMENT those requirements is more art than science.
Engineering presumes that there are canned rules and "how to" guides to guarantee a program's reliability or a building's safety. There are no such guarantees with software, no matter how thoroughly you test a system. The only exception are "mathematically correct" theoretical languages that no one actually uses for production systems.
Keep doing what you're doing. Getting an engineering-focused degree will NOT help you find employment.
Good luck with your career -- I think you're off to a great start with your approach to coding techniques.
I do not fail; I succeed at finding out what does not work.
Linux used in any critical task would probably require at least some review by any organization relying it (probably including NASA, DoD, Google, Red Hat, IBM, etc).
Organizations of that size often also get to review closed source code before using the product in question.
Books
Peopleware by DeMarco and Lister (and any of their other books)
Capers Jones' latest book.
Gerald Weinberg's books.
The Inmates Are Running The Asylum by Alan Cooper (UI design)
Software Engineering Economics by Barry Boehm (somewhat redundant with Capers Jones, but still a good read)
Technology
Keep current with latest trends to stay employable. Unfortunately, not many companies hire software engineers; they hire technology experience.
If you get tired of laboring at the 3GL "abstraction level" (Capers Jones' data will reveal the need for quotes), you should look at Executable UML as described in the like named book by Stephen Mellor and Marc Balcer. Other authors in this field are Leon Starr and H.S. Lahman (Model-Based Development), and another book by Chris Raistrick, Paul Francis, John Wright, Colin Carter and Ian Wilkie.
Because Computer Scientists who think they are Software Engineers write it?
It sounds like you're more interested interested in the Quality Assurance aspects of the industry than programming. You can be one or the other, but not both, at least not on the same project.
It is normal for QA to be handled separately from programming so that the testing process can cover cases the programmers didn't allow for. It's an entirely separate discipline of the software process, and you are correct, there are standards and rules if you choose QA as a career path.
Just be aware that it takes a special mindset to enjoy QA work -- most programmers hate it because a lot of it is checklist regression testing and running automated test scripts, and programmers usually prefer a more creative career path.
Even without a career in QA, I strongly recommend that you read up on Six Sigma and ISO9000 to understand what the goals of those approaches are. Software creation and testing are a process, and both of those approaches rely heavily on documenting and improving the process over time to reduce the bug reports and improve the quality of delivered code.
I do not fail; I succeed at finding out what does not work.
Engineer and doctor are both protected terms in many places, and you cannot hold either title (i.e. on a business card) without accreditation from respective authorities. Misrepresenting yourself as an engineer won't get you more than a lawsuit and fine, but misrepresenting yourself as a doctor can get you jail time.
In parts of Canada, Microsoft was forced to only refer to their certifications as "MCSE", never expanded to "Microsoft Certified Systems Engineer".
There's similar attempts to protect the word "architect" although that's a more recent development.
"Really, 95% of the software development employees out there are just using these rigorous methodologies to try to emulate hacker-ness, because they can't otherwise muster it naturally."
Huh? Never seen this before.
The usual difference is that 'engineering' is about understanding and dealing with the realities of other humans: your colleagues, your bosses, and your clients, and yourself, and not just your code and your problem and your shiny toy.
Don't change a thing my friend. Code your own code, but keep an open mind to things that will make you better. If a company chooses not to hire you based on your static skill set rather than your potential then you don't want to work there anyway.
The best advice is do what works for you, not what works for the guy that sits beside you. Linus vetoed debuggers in the kernel for years and that code runs half the planet.
Get input from others on your code. Have opportunities to review and comment on theirs. Both will grow your skills quickly.
Engineering is all about process. To transition from hacker/cs-grad to software engineer, you need rigorous developmental processes that guide how you specify (requirements), design (modeling), write (coding practices), build (turning code into runable programs), test (unit and system), document (in-line, reference, and user), and preserve (version control and release management) your work. Until you have internalized and utilize such processes, you will remain a "hacker", not an engineer.
Sometimes, real fast is almost as good as real-time.
...smart
Bukowski said it. I believe it. That settles it.
Leverage what you know by choosing a company that that uses an agile method: it's not "mechanical engineering", but it's definitely engineering.
--dave
davecb@spamcop.net
Because you're not that old, you're not familiar with the Debug.Print command, which has been implemented in every language I'm familiar with in some way. Think of it as a IDE variable watch that outputs to a scrolling list.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
There's an old joke about a theoretical physicist who solved the problem of the chicken and the egg. Problem was though it only worked with cubical eggs and spherical chickens.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
Engineer is a professional designation in most jurisdictions - it requires a degree in engineering or equivalent qualifying exams as well as membership in the professional regulatory body. It would be illegal to represent yourself as such and you can face fines for even using that term in your commercial representation.
Now, I know this isn't exactly the meaning of your question. But engineering involves a broader exposure to technology in a number of fields to produce a holistic design. Computer science is a more specialized area of knowledge dealing with just one technology: coding of software. In my experience, this contrast sums up the shortcomings of computer science majors I have hired in the past. And I think that is the answer to your question, if you think about it.
This would require management moving beyond the mindset that any software project that is in R&D for more than four months is a failure (because three months is the SEC reporting cycle, and therefore, any project that isn't turning a profit by the next reporting cycle is a failure).
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
My god, having a kid turned me into an engineer!
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
Nope, that's the customers. Management are just the conduit - and a leaky one at that.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Depends *HOW* you misrepresent yourself as an engineer- and how many people are killed when that bridge you designed falls into the gorge.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
A computer scientist who's also a programmer not only does the same thing but with the added goals in mind of making his code the most efficient running code possible on the target platform while understanding why a particular collection of code is the most efficient it can be upon the target platform.
Which is EXACTLY why software development programs tend to be massively over budget and often don't work properly at the end of the day. Like who gives a rats ass if the matrix multiply is the most efficient it can possibly be if the overall system still meets the requirements with an inefficient matrix multiply?? You people spend so much time optimizing the academic worthless shit that there is no time left to actually finish the project, and then you blame management for unrealistic deadlines. Just get it working, make sure the code is clean and easy to understand, and move on to the next task!
Tesla was a genius. Edison however was a overrated hack who liked to torture puppies.
There is planning, debugging, managing, maintaining, documenting, and selling it. Fresh-face kollege newbies think the percentage is the other way around. If you are lucky your company will offload some of these tasks to specialists, allowing you up to half your time coding.
My current company is conglomerate of about 40 startups around a special vertical theme (energy). The startup phase is a lot about writing code. Its only a minority activity here. But then I dont have to travel to Abu Dhabi to sell or manage my code then, which is often the beyond the capability of a startup.
The dirty little secret nobody admits to is that what you described as 'hacking' is software engineering in the real world. Software development is a black art which all the methodologies in the world will never reduce to a simple recipe guaranteed to produce better code.
The only difference between software 'hacking' and software 'engineering' is the amount of testing.
Indeed... I noticed that omission right after I submitted the comment, and made sure something like that was mentioned that in my next comment.
"You're right, but there are for example lots and lots of eyeballs on the Linux kernel source. Also, at least FOSS has this possibility (and while not always being reality, it is sometimes)."
So how is that any different from what I said?
"Yes there can be profit in FOSS"
Of course there is.
"but its not usually from the software itself"
Quite on the contrary, it is usually from the software itself. Where it is usually not the case is in the closed source camp. Usually the revenue for closed source software developing companies comes from anywhere else but the software, typically, the licenses. The open source software developing companies, on the other hand, more times that not get their money from the very exercise of developing software itself.
"(by definition "free" as in usually both "free beer" and "freedom")"
By *YOUR* definition, you mean. In every other case, FOSS is about "free as in freedom" disregarding if it is "free as in beer" too or not.
"The "features on demand" that you mentioned, if sold for profit, aren't really FOSS are they"
Of course they are, how they couldn't be? I don't think you understood -which, by the way is no surprise since it seems the vast majority of people seem not to be able to grasp that the main source of revenue for a programmer and, by extension, for any company centered around software development should be... developing!
The company developed a somehow niche application and published it under an open license (GPLv2). Each time the company gets a contract to develop new functionality for the product it goes open source to the main product, which in turn makes it more attractive to new customers. Rinse and repeat. Add to that 24x7 managed services and support for the product and there you have a business plan.
It might happen the day comes that no new features are desired for the product (it's still far away but it might happen). On one hand this company is still the worldwide expert for the product so even in its "dog" phase it still will bring revenue for the company. On the other hand, part of the benefits during the "cash cow" phase are derived to R+D to create the next application to repeat the strategy.
"Hacking has evolved beyond the original "tinkering" definition of yesteryear. It's now associated with unauthorized access."
That was obviously not the meaning attributed by antifoidulus when sent the question.
""Hacking something together and pushing it into production" might not adhere to all the rules of extreme programming,"
It is not that it doesn't adhere to some rules but that it is against its very spirit. I won't consider here that all these "extreme" chaff is more about managing people's expectations than project management but on its technical side is about *guaranteeing* enough quality and serviceability despite the speed: it is the realm of unit testing, of continuous delivery and of standards adherence.
"As long as any software produces the correct result, how it achieves it is usually of secondary importance."
Exactly. And to insure this to happen quite a lot of things have to be considered, the main one being what the "correct result" is to start with. For a long running project part of the "correct result" necessarily is how maintainable is in the long run; for a highly distributable one, how deeply coupled or how scalable its elements are, etc.
And, in the end, any engineering is not about if it produces the correct result but how likely is in advance that the correct results *will* be produced. And, regarding software, that's the difference between hacking and engineering.
First off, there is no such thing as Software Engineering. Engineering implies replicable best practices to solve a common problem, e.g. building a bridge. There are standards, licensing, courses, and an apprenticeship which teach the standards and practices.
Besides, there are two possibilities in software, either the problem has been solved or not. If it has been solved then just buy it. Don't reinvent the wheel. If it hasn't, then you are in the world of research and development. This is where the science comes in. You have no real guides, so you start by sketching out a proto-type. You then try to implement it and test it all the way forward. It's the hypothesis/experiment approach. This is why testing is so crucial in software development. If it doesn't pass the tests, try something different.
Engineering implies canned solutions. In full scale software development there are no canned solutions.
putting the 'B' in LGBTQ+
I personally know of two people with masters degrees in CS granted from a respected State University that know squat about programming, let alone the process of engineering.
I'd be better off hiring a high school drop out to help me program.
In my experience, people who didn't get an undergraduate degree in Computer Science/Engineering, and don't have an underlying interest in software, but got Masters Degrees in Computer Science, have all turned out to be the most incompetent Software Engineers I've ever worked with, because
a) they have no underlying knowledge of how programs actually work
b) they think they are experts just because they have a "MS in CS"
No it's research and development.
putting the 'B' in LGBTQ+
> how do you make the transition from hacker (in the positive sense) to a real engineer?
I like your question. Start in a software engineering position,
try to do your best while still respecting yourself;
_engage the people around you_, find the people you resonate with.
Look calmly at your mistakes and at different perceptions and points of view, try to learn from them.
Try to keep a high spirit and a playful attitude.
Do not bash other people even when you feel you are right, learn to negotiate.
Sometimes it is better to at least discuss a non-optimal but still good solution,
rather than trying to force what you perceive as the optimal path, at the cost of burning all bridges around you.
Work relationships and the work environment need to be taken into account.
At the same time, reality cannot be ignored.
I would tell these things to the myself of some years ago. Whether that would help, I don't know.. we probably need to learn from personal experience in the end anyway. But maybe some road signs along the way pointing into some general direction can help at least a little bit.
Good luck, good journey.
I very much doubt that any organization would be allowed to review Windows kernel source code (regardless of budget), but we might just have to agree to disagree there.
The company developed a somehow niche application and published it under an open license (GPLv2). Each time the company gets a contract to develop new functionality for the product it goes open source to the main product, which in turn makes it more attractive to new customers. Rinse and repeat. Add to that 24x7 managed services and support for the product and there you have a business plan.
you forgot the bit about how you actually make money from that, given that your "customers" are free to seek extensions from elsewhere after pillaging your freely available "main product" source code. seems like a pretty risky business model (particularly if you have greedy shareholders to look after), but I don't work for a FOSS "company", so ok.
other FOSS companies (MySQL AB, Red Hat Inc, Canonical, etc) sell support contracts, which may include development of extensions, but their "main product" is released for free (as it must under GPL terms).
on its technical side is about *guaranteeing* enough quality and serviceability despite the speed: it is the realm of unit testing, of continuous delivery and of standards adherence.
no, its about focusing on incremental results and allowing for changing requirements. perhaps you've never tried it (since you don't seem to have much regard for it)
main one being what the "correct result" is to start with
clients rarely know exactly what they want at the start of a project (they'll give you a highly subjective and obscure top level goal written in management-speak because that was who it had to convince in the first place to get a budget for it, and then "you're the engineer so you go figure it out" is usually what follows). what client talks about results in terms of maintainability or scalability? they are usually interpreted as requirements by the engineer from the various meetings with the client that never actually feature those words.
any engineering is not about if it produces the correct result but how likely is in advance that the correct results *will* be produced
i can tell you as a professional mechanical/structural engineer that if you're not sure that you'll produce the correct results in advance, you shouldn't be an engineer in the first place. as someone who also develops engineering software, if you only focus on the final result from the beginning, you will never finish your project because the final result always evolves, especially if you want to stay in business (its called shifting the goal posts, and managers in every organization are exceedingly good at it). if you spend a lot of money developing something that achieves a specific objective, when the client says they want to change something, your contract will lose some of its appeal because it will cost them more to change than a contract that provides flexibility via extreme programming
If only everything was being over-optimized! If only!
A big one is that clarity and maintainability in the source are more important than cleverness. That's not to say it should resemble Cobol or anything, but it is necessary to keep in mind that one day years later, someone who has never worked on the code before will need to make a change somewhere and won't have time or desire to appreciate clever obscurities.
Go download some open source program you haven't looked at before. Pick any little change that might be useful or at least could make sense and try to get it done as quickly as you can. Do that a few times and you'll have a feel for what I'm talking about here.
Engineering is http://ieee.org/
Hacking is http://programming-motherfucker.com/
Problem:
The application is too slow!
Hacker:
This random piece of code looks poor.
I'll put in some uber-tricky stuff that is highly optimized to make the compiler do what I want and destroy all chances of reading the code.
Release
Engineer:
In what way is the application slow?
Show me how to reproduce.
Profile
Examine
Optimize hotspots.
Test
Release
I drink to make other people interesting!
in canada - you are not an engineer, unless you've been professionally credited as an engineer.
what you are is a professional software programmer — to call yourself an engineer when
you are not is akin to adding a: PhD after your name when you never actually received those honours.
so stop abusing the term.
(i'm an amateur coder myself, but i strive for excellence in what i do)
best regards from toronto island
j
Isaak Newton put it well —
A vulgar mechanick can practice what he has been taught or seen done,
but if he is in error, he knows not how to find it out and correct it;...
Whereas he that is able to reason nimbly and judiciously about figure,
force, and motion, is never at rest till he gets over every rub.
(Isaak Newton, in a letter to Nathaniel Hawes)
that about covers it.
2cents from toronto island
jp
"you forgot the bit about how you actually make money from that"
I told you: by contracting on the development of new functionality (and engineering the solution, and deploying and supporting it). This is not an idea: this is already working.
"given that your "customers" are free to seek extensions from elsewhere"
Truly. That's as true as that you can go to Seven Eleven searching to hire quantum mechanic experts. Quite a different issue is if you'll find them there. We are talking here about a non trivial piece of software, and it happens that this company know it in and out and have the marketing and sales strengh to push for it. Not many other companies can say the same but, hey, the market is free both for the customer and the provider. If they find a better bargain, lucky them.
"after pillaging your freely available "main product" source code."
The Merriam-Webster define "pillage" as "the act of looting or plundering especially in war" or "something taken as booty". Given that this company wholeheartedly gives the source code to its customer under the GPLv2, I fail to see
where the pillage exactly is.
"seems like a pretty risky business model"
In fact it isn't, given that most service companies use it in that they attract money as they work for it and money stops flowing the day they stop working... or it wouldn't be a risky business were it not for others that use their strengh not in making better products but in lobbying legislation for clearly anticapitalistic practices (like creating artificial scarcity by means of government-granted monopolies on IP).
"perhaps you've never tried it (since you don't seem to have much regard for it)"
Or perhaps my regards about extreme practices come from a deep study of what they mean and how they are implemented, who knows.
"i can tell..."
All well and good and absolutly orthogonal to the issue at hand. But, hey, it's you the one asking "what client talks about results in terms of maintainability or scalability?" and I was the one telling that agile practices were more about managing people's expectations than anything else.
I cannot say it better than Rands himself: "In Software Engineering, the Process is the Product"
Read Rands in Repose.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
The problem comes down to you get a developer who believes the beauty of the code is the only thing worth looking at. He then gets assigned to add some features to existing code, looks at *other* parts of the code that don't need to be changed, are completed and are fully tested, reacts with horror saying 'what idiot wrote this piece of crap?!?' and then proceeds to spend a month rewriting it, breaking multiple other things in the process cause he doesn't understand the code. THATS the problem and it happens ALL the time.
Tesla was a genius. Edison however was a overrated hack who liked to torture puppies.
From personal professional experience I can think of at least two organizations (both rather large) that have access to the full MS Windows source, and suspect there are quite a few I don't know of. Both maintain considerable organizational controls around access to the source (contractually obligated, I suspect). I'm not sure what my non-disclosure agreements say about the two cases I know of, but a quick google turns up several other examples (that I personally know nothing of) such as:
http://www.informationweek.com/news/software/operating_systems/225400063
http://www.zdnet.co.uk/news/security/2010/07/08/microsoft-opens-source-code-to-russian-secret-service-40089481/
...and even a link to how you ask for it yourself:
http://www.microsoft.com/licensing/software-assurance/enterprise-source-licensing.aspx
You mean like all the times when there have been exploits to *nix software that happen everywhere except some *BSD version that already saw the sloppy code and cleaned it up in their port?
Haha, well said!! Got a developer that works for me who is always late on every project he is involved. So one day I sat down with him trying to understand why he was always late. Was quiet an eye opener when I realized he was effectively rewriting the code 3 or 4 times per module.
He said he wasn't done until the system was perfect. Now I am all for optimized code but number 1 priority is a working complete solution and then it can be re-factored to improve efficiency/re-writeablity/etc.
No I'm not talking about sloppy bad code with bugs that allow exploits. I'm talking functioning *working* code that's been *tested* to be correct, but don't happen to match the aesthetics standards, or 'wow that's a cool way of doing it' standard of a developer that thinks hes top shit. Problems have to be fixed, but changing code to make it more elegant or efficient when there is no performance reason to, or making it run in 3 lines of convoluted code instead of 10 or 20 of very clear easy to understand code is just moronic.
Tesla was a genius. Edison however was a overrated hack who liked to torture puppies.
Completely agree. The first run through is to get it working with simple, very easy to understand code. Absolutely nothing fancy. Once it works, THEN you check the performance and optimize only those modules that need it. Simple code is far more likely to be bug free than come convoluted pile of packed code that no one but the writer understands. For some reason coders take pride in the fact that they can write code that works but no one else can read (even though the simple version would have taken an hour and they took a week). Baffling.
Tesla was a genius. Edison however was a overrated hack who liked to torture puppies.
i do the same thing. i just avoid VB wherever possible. all other languages i use call it something else, though php has print_r. i've been a bit spoiled having delphi (object pascal is probably the most strict and typecast language i've used, which makes debugging much easier)
Well, then Debug.writeln; I code in a wide variety of languages, but I'm currently paid to code in VB.
I find actually I get more errors the more strict the typecasting is, as a rule. I absolutely hated COBOL, where even your comments are syntax checked.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
If you think you're "missing something" regarding software engineering, have a look at the SWEBOK, published by computer.org. It's a bit out of date, as it's lacking in security and quality sections, but it does have a compendium of knowledge.
As far as the actual practice of software engineering at a large company goes, my list looks like this:
1. Testing, and particularly developer-driven testing using automated unit tests. Why are you writing code if you can't prove it works? More importantly, why would your boss pay you to write code that you can't prove works? Really, if you learn nothing but Test Driven Development, you'll already be ahead of 50% of the people who call themselves programmers (including 50% of the commenters above spouting nonsense like "just keep doing what you do".) Of course, once you truly get it you'll realize that it touches all the disciplines of software engineering and design, and that a well-written test serves as your best documentation. And don't forget usability testing.
2. Design patterns. Civil engineers understand materials and shapes, and use tested and measurable components to accomplish tasks. A civil engineer doesn't need to reinvent the I-beam to build a bridge, they know the I-beam pattern exists and that that if they use them, they obtain performance of X, but have requirements of Y, and side effects of Z. Similarly, a software engineer should understand patterns serve a somewhat similar function in our domain. Pub/Sub will act this way, and it scales this way, but doesn't address retries. Note that patterns are abstract concepts, which makes them distinct from libraries or frameworks. I trust a pattern, because it's mathematically understood to behave a certain way. I don't have the same implicit trust of libraries and frameworks, because those are code implementations that may or may not be 100% correct.
3. Design principles. I like the SOLID principles myself, as I think they're exceptionally clear.
4. Security. Understanding concepts like default deny vs default allow, input validation via whitelisting or blacklisting, sanitized outputs, etc., are crucial in the modern world. Check out OWASP and SANS for long, long lists of reasons why security matters to software engineers.
As an engineer, it turns out there's an awful lot you have to do that isn't directly programming, but is still important, either to you, to your software, or to your company. So the list keeps going.
5. Estimating. If you end up at a shop that isn't at least Agile (I am, and I wouldn't recommend it) you'll have to provide estimates. Experience is the primary teacher here, but you may find modeling tools like COCOMO II to be valuable.
6. Code reviews. Understand how to hold an effective peer review, one that helps improve software quality without making the coder feel like an idiot, or afraid for his next review score.
7. Methodologies, processes, metrics, regulations, standards, and governance. Waterfall, iterative, RUP, Agile, emergent design, test-driven, behavior-driven, lean, all are processes for writing software. Processes also cover things like source code management practices, defect tracking and fixing, project management, etc. At one level metrics are useless things managers want to see regarding productivity, but as an engineer you can use them to help understand code written by others. Standards and governance likewise exist primarily to make the people signing the checks feel like you're doing something for them. They may not matter in a one-man shop, but when you're in a big organization, leading teams of developers, or working with offshore teams, these take on a level of importance that you unfortunately cannot ignore.
There's a pile of other stuff, of course. Data modeling, software architecture, packaging, deployment, languages, the UML, optimization, encryption, key management and certif
John