I would argue that the term "bug" is appropriate for most software development. Elevating the symptom to the level of "error" is giving the programmer (and the process) too much credit. Most programs are put together with very little up-front thought (design?), and are then exercised while incrementally fixing the bugs in the code. This process is repeated until all (or most) of the observable bugs are discovered. This is properly called "debugging," and has little to do with eliminating errors.

What's more, even the elimination of that last observable bug is no indication that the program is free of errors.

In my opinion, errors are the province of design and bugs are the province of code. Until we start actually doing design, the term error has little meaning.

I absolutely disagree with Dijkstra stating that the euphemism "bug" be replaced with "error". Yes, we all realize they're errors, and we realize from where and how they originated. But the fact is, bugs are a way of life in our world. What purpose would be served by emphasizing developer mistakes? To make them feel worse? If you argue that it would reduce their occurrence, I'd have to see that to believe it. My thoughts are that this would reduce morale and job satisfaction and not have any measurable benefit.

I used to used SnagIt and suffered from the same issues as you.

I have moved on to something that I have found works better... I use the screenshot feature in Dropbox, then edit that with FastStone Image Editor:

http://www.faststone.org/FSViewerDetail.htm

FastStone is lightweight and snappy...it is a full and complete image editor.

Using the Dropbox screenshot feature has a side benefit...it allows me push one button to save the screen, which usually has many more things I want to save. It also make the screenshots available across all of my machines (9) so I don't have to fool around with manual file transfers. Here is how to enable that feature:

https://www.dropbox.com/en/help/1964

http://www.picpick.org/en/

Screenshot / simple editor. Free for personal use; $25 for commercial use.

I'm seeing the same problem, and heck I am guilty of wanting superhero-like grads. This is the advice I am giving based on how I prepared during my MBA(yes, you can still be techie but understand marketing).

1. Create a portfolio (on paper, online, presentation, whatever) that not only has your academic accomplishments but more importantly can show your passion for your work. This can be done sometimes through the Open Source community but can be difficult to get results to work in your favor. Instead, I recommend for firmware and EE types to make their own hardware-based projects and treat them as a display not only your passion but your commitment to keep learning and refining. I recommend this even for those just looking to move to a different career. Now is great time to spend $100 (or less) and make something you can demo at interviews or elsewhere.

2. Meet people in the industry and put yourself out there. I am guilty of this: I went onto engineering thinking I could avoid the people stuff. You can't. So you do need to meet people and go to events and meetups centered around what you want to do as a career. If you are not in Silicon Valley I suspect this is more painful to do. Get on the various blogs and redits and start talking (Isn't the HackADay prize starting up again?). Find places to show off your projects from part 1. If you cannot find your place, make your own space and meetings. People are much more likely to want to talk to you if you are running the show.

3. Specific to new grads: In the interview, try to do the problem given, but also pay attention to the hints given and take direction. It's ok to say "I don't know." In fact, it's a sign of maturity as an engineer.

From my perspective as someone looking to hire, I'm expected to bring someone on who has solid basics, works beyond their silo, and show some amount of self-directing because there is so much to do. Many of us are looking at resumes and noticing who has created their own startups (apparently, everyone which I truly doubt), who has projects online (github and other places), commits to open source, and we are scouring hacking sites, hackathons, and tech contests to find these rare people. Unfortunately, not doing this yields poor interview candidates who can barely program or demonstrate basic skills and this happens whether the candidate has 0 year or 20 years of experience. It's depressing.

Enough ranting. I am really rallying for some fresh blood in the firmware space. I am the "young" firmware engineer in my office and I'm quite accomplished as I am getting close to 20 years of experience but finding people with < 10yoe is hard.

My advice to new grads is to show some interest and self-directed study in the field before applying for the job. When I first graduated, I brought in a home-built, RC car into job interviews and I found that the interviewers didn't even care about what technologies I used, or how capable my project was - they were more impressed that I showed a passion for working on something similar to what the new job would require. These kinds of applicants are rare (unfortunately), but they also tend to be the best hires since they are eager to learn and are excited to work on real engineering projects.

I have now been volunteering my time at the local university to teach an extracurricular embedded hardware/software class, where students solder a PCB kit, then program the embedded software on it - building up from basic drivers to some sort of year-end project. The program isn't perfect since students have so little time to devote to non-credit activities, and many students drop out once the soldering is finished and the "tough" software part begins. However, for the students who stay to the end and show that they are truly interested in the field, I have usually been able to offer them a job, or put them into contact with other companies who could hire them.

On the flip-side, I've also noticed a problem with many new graduates where they are only looking for a job that will "hold them over" for a few years so that they can get their magical experience. In those cases, I wonder why I should bother training them and getting them to be productive if they're going to leave right when they're starting to finally offer a return on my investment?

Besides the goodness things you mention for prepping for a job, I would add "do some hobby engineering work". If a fresh grad does not have a job yet, then they had best have a very serious active side project that stretches, hones, and showcases their job skills. Pick a problem, and develop a solution. Even better, develop a solution for someone else, or help a non-profit or school using your engineering skills. Working with other people helps demonstrate and grow your soft skills that are necessary in a workplace environment.

The tool chains, circuit boards, and information have never been more accessible than they are now. If a person is not willing to invest a couple hundred dollars in themselves and their career while they are unemployed, then I don't want them on my staff either. Buy a Raspberry Pi, and do something with it. Most likely, you will learn something that school did not teach you.

A sure way to miss my short list is to look for work in the engineering field for xx months (even if you were employed doing other subsistence work), and do nothing to further your engineering skills since graduation. A natural born engineer *needs* to engineer, just like other people need to eat and sleep. If you are not engineering (if only at a hobby level), then I deduce that you are only educated to be an engineer. If that is the case, I don't want you.

There is also the simple fact that the marketplace weeds out people that should never have taken an engineering curriculum in the first place. Just because a person spent the money, passed the tests, and graduated does not mean that they have the natural capacity to be an engineer. Some of this should be blamed on schools (and advisors) that are not honest with their clients (the students) about their abilities. Some people can master all of the knowledge of an education, but they just don't have the engineering "spark". Therefore, there will always be some fraction of graduates that don't (and shouldn't) get jobs in the engineering field.

Harsh, but true.

I think new grads need to take a page from our artistic friends and set up a portfolio. It doesn't necessarily need to contain work from a large scale open source project, but it does need to show the "give a crap" factor; I need to know the perspective employee isn't just going through the motions with their schoolwork and expects a job in return. When I was hiring at my previous jobs, my main goal was finding young engineers with enthusiasm about the field. I'd take a B- student with a portfolio and an eagerness to learn over a valedictorian who sees engineering as a path to something else in life. Me and Dave talk about this a lot on The Amp Hour: If you walk into a job interview with PCBs in hand ready to talk about what you're holding, you're going to get the job.

Getting the interview remains the elusive part and I think that having a portfolio can help with that. What goes in the portfolio? A YouTube address, a GitHub account, a personal blog detailing your builds, a Hackaday projects account, a flickr account showing pictures of your projects or a twitter account where you're discussing technology... there is no formula (which many people look for) except enthusiasm for building and programming things. Similarly, there is no formula for getting past the gatekeepers at large institutions: If you want to work at IBM (eesh, why?), you're going to have to get through their standardized system. A portfolio will still help with that. But if you want the juicy job listings that don't show up on Monster or Indeed, you talk to people, you share your projects online and things will come to you. All of the GoogleX people I know (granted, that number is 3 of a much larger group) were YouTubers first. How's that for a sea change?

Of course, I am very biased. I teach a course about how to build electronics online (Contextual Electronics). We don't have letter grades. We don't have pass/fail. I believe that the future of learning is not tests but is tangible output, in our case hardware that is designed and built by the member. I also encourage encourage to document on their own sites and talk through their learning process as that can be as important as the output (and proves the effort they put into their work). I don't know what the future holds for employers choosing their employees, but I am pretty secure in thinking that project based education is a reliable way to learn.

The military often makes people grow up by providing, for the first time in a person's experience, an environment where what happens to you depends directly and consistently on what you do.  As Forrest Gump put it, "All you gotta do is what they tell you."

Make as much of an investment in your job search as you did in your classes. We regularly hire interns from around the country. Those who have the passion to be here will find a way. One guy last summer lived on the very minimal pay we gave, using most of it to pay for housing in a local long-stay discount hotel. He had passion for the products, and went back to school in August with a conditional employment offer (finish your degree with good grades). He's doing his senior year knowing he has a job because he invested his summer internship wisely. Having a passion for the work, learning, and doing were all essential elements for our decision to hire him come May.

I guess that gets back to your Discipline comments. AMEN to them!

One of the best pieces of advice I can offer engineering students is to participate in their university's co-op program. Sure, it takes a little longer to get that degree, but you'll gain real-world work experience that looks great on a resume. When you graduate, your co-op employer is very likely to offer you a job. I was a co-op myself and began thinking of it as the perfect lifestyle. While I was working, I had my nights and weekends to myself again, not to mention some money in my pocket. When it was time to return to school, I was reenergized and excited to jump back into my studies. Now, I'm a hiring manager, and I love to see co-op experience on a candidate's resume.

The best recommendation I have is to get an internship or find a job as a technician while in college. The college has job postings, probably from former students looking for help.

That's what I did. I worked part time as a technician during my junior & senior year. They hired my after a quick interview and I've been working as a EE ever since (40 years).

Regarding advice for new graduates, a person I've come across who seems to have a lot of good advice on looking for new employment is Liz Ryan at http://www.humanworkplace.com - worth a read.

I run a small software company and really struggle to find new talent, but I understand why people aren't too interested in graduates. Having invested a lot of money in their own education, they expect at least 50% more than an equivalent school leaver, but have exactly the same experience - none!

I've seen other small companies take on graduates and invest a lot of time and effort in their training. They often don't start producing useful work for 6 months, then after 12 months go and find work at a bigger company who can afford to pay them more. The cycle then begins again with the next batch of graduates. Small companies effectively become unpaid training agencies. I'm not sure what can be done about this problem.

Some of the discipline you mentioned within the latest Muse applies to the job hunt as well. However, the search for the job for when you graduate must begin much earlier than graduation itself.

Plenty of organisations have programmes that take in students part way through their career (summer interns etc) and short term opportunities that should prove useful to the graduate by way of gaining some experience within industry. Try <http://www.studentladder.co.uk/> for the short term opportunities and <http://www.gradcracker.com/> for the 6 month or 1 year internships. Each of these will count as experience on the CV.

I am still of the opinion that the Modern Apprenticeship is another route that those wishing to enter engineering careers should explore. Practical on-the job and college and university courses built to support such programmes will give those who partake experience dating from their first entry.

What can new grads do to increase their chances of getting hired out of the gate? Build demonstrable stuff. Invest in some developer kits and build something you can bring to an interview and mention on your resume. Raspberry Pi's are dirt cheap. So are TI MSP-430 and Microchip and a host of other developer kits. Being in a position to hire engineers, this is the type of thing that not only interests me personally, but it demonstrates motivation and ability. And put your projects in a public repository like GitHub and reference it on your resume. Give me 5 minutes with your code and I'll know if you have the right stuff or not.

The suggestion to contribute to open source projects isn't bad, but wouldn't carry as much weight with me personally.

The company where I work strives to hire 60 to 75 percent of new hires from our student pipeline. At any given time we may have 100 to 200 interns or students on staff. These students work directly with engineers on a daily basis. The students learn what it truly means to be an engineer while providing extra hands to make the engineers more effective. When the students graduate with a degree they also graduate with between nine months and three years' experience making their transition much simpler. Recently we have seen a trend where fewer and fewer students are looking for internships. At this point it is normal for us to have unfilled positions. My advice for any student would be to look for an internship or student position. They are available. If your grades are too low to find such a position it may be hard for you to find a position when you graduate as well.

A few thoughts on new grad employment:
- It's not all companies that are asking for experience before hiring. We are a small division of a larger company and have hired two new grads in the past two years. We also typically attend local on-campus recruiting events every year.
- Internships would help these grads get a little experience under their belt prior to graduation.
- They may not want to hear this, but the fact may be that they need to go were the jobs are ... this may require moving to a different city/state. I know this may be difficult for a new graduate ... make sure the company hiring them is willing to pay for the move.
- Take a look at federal government positions, or maybe even state level ... utility companies, and maybe think about starting there vs in a commercial position. Some of us have done just that. Keep in mind that some of these have citizenship requirements.

Would be interesting to hear what others have to say about this topic. I keep hearing about the government pushing STEM programs ... how big of problem do we have in getting recent grads employment?

When I graduated with a CS degree in the late 90s I had internships at three different companies and some freelancing under my belt.

Maybe the world has changed a lot for undergrads since then, but I know that both my current employer and a couple of prior employers over the past decade have had active internship/coöp programs. These kinds of employers are generally in the habit of making job offers to interns when they graduate.

While internship experience does help make a fresh graduate's résumé look good, the contacts you make at these companies are far more valuable. My first three or four jobs came from contacts I had made at these internships. Back when linkedin was more relevant, I put up a note that I was looking for work, got referred to an unposted opening via a manager at one of those internships several years prior, and had a job offer within a week (and this was during a period when jobs were thin).

Even if you don't get a job through these contacts, at the very least you have professional references.

I'm not much of a believer in the blind résumé. You'll get hired *much* faster if you have someone on the inside who will put your name directly in front of the hiring manager and make a recommendation.

Bottom line: if you're waiting until your last semester -- or after graduation -- to find full-time work, you're doing it wrong.

Perhaps open software project experience doesn't provide much advantage (really?), but I must say that one job applicant's experience as a team member in an engineering competition was a critical influence for my selecting him.

Had I encountered any resumes indicating open source software accomplishments, I'd certainly have given them as careful attention as I would for any other relevant accomplishments.

I would have also been interested in seeing demonstrations of any example work product, especially self initiated product.
Application(s) developed by an applicant and demonstrated on a smart phone, tablet or laptop might enhance one's credibility.

However, I'd point out that job interviewing is a two way street. Each applicant wants to gain opportunity while the interviewers, purportedly, want to gain additional work capability. If the interviewers are so myopic as to only look for directly applicable prior experience, there is a good chance that the opportunity is not so hot.

While getting the first job is important, even more important is getting the opportunity to experience high quality work challenge.
A dead end position is not a great career builder.

I have a few thoughts on hiring new graduates.

I am working for a German based multinational company in Serbia. The Germans schooling system includes at least half a year of apprenticeship at a company. This interval is beneficial both for the student and for the company. While the student gets a good practical training in the field of electrical engineering (or software engineering) the company benefits by getting some project work done which has lower priority and never was important enough to get an engineer working on it.

Unfortunately in Serbia we had no such apprenticeship for the time of our studies. We tried to compensate this by choosing a thesis which was complex enough to prove ourselves. For the time of our studies we were freelancing on various smaller projects not really for the financial benefit but for the experience we gained through these. (ranging from a simple programmable timer circuit for some friends to a GSM module based alarm). This turned out to be quite a good idea.

When I applied for a job I did not have any official experience at any company as a fresh graduate, but I had a lot of reference designs from the previously mentioned projects.

Nowadays I am interviewing candidates for the open positions at our company. It is very hard to spot the applicants who have a desire to work hard, learn hard to earn a respected position. You draw a simple transistor circuit on a whiteboard and they seem to have no clue about its purpose.

I try to encourage students to take some complex bachelor/master thesis and do any project that crosses your path.
Even if you only have a few dinners to gain from these projects financially, they can earn you a good job at a company someday!

Thought I'd weigh in a little bit on the IDE debate. I realize that I'm a bit of an outlier in that I did a full computer science degree as well as EE, but I've worked out a process that seems to work well for me and the folks I work with: GCC and Makefiles. I've mainly worked with 4 platforms: AVR, MSP430, "microcontroller ARM" i.e. Cortex M, and "processor ARM" i.e. Cortex A. Once the bit of grunt work has been done to get a toolchain set up, the guys who like IDEs can use them (anything can run a Makefile!), and the guys who don't can still build the code. I write the vast majority of my code in Emacs, which I don't expect will be going away any time soon. All of the code is in version control, of course, and the Makefile is set up so that there's usually only two required commands: "make" to build the code, and "make program" to flash it over whatever our default process is.

When I'm learning a new architecture or codebase, I like to feel like the majority of my effort is going into understanding those things instead of trying to understand yet another processor-specific IDE.

As a side benefit, I don't have to spend kilobucks on tools that... well... I'd rather use emacs instead.

I'm going to chime in on the IDE discussion, with the input that an IDE is generally unsuitable outside of the developer cycle.
At some point, someone other than the engineering team will need to build it, and will generally use a command-line oriented tool to do so. This may happen very early on in organizations that perform nightly builds, or may happen in a rush at the end of a project when a release version is due.

Most IDEs I've used don't have good support for that kind of usage, or may only support it IF you essentially disable their automated build system and fall back to creating Makefiles or batch files to be used from bash or cmd.exe or whatever.

The other issue I have with IDEs concerns vendors who base their software support on the otherwise really nice Eclipse environment, but don't integrate to it in a way that allows the generic platform to be updated without breaking the vendor toolchain support (*cough*WindRiver*cough*Xilinx*cough*).

This may or may not be intentional (to only need to provide support for a single IDE version): the Eclipse framework is quite extensive, and quite complex in and of itself.

My objection here is that vendors try and put too much 'added value' above and beyond providing automatic plugins that simply provide their code generation/analysis/co-design interfaces. Keep it simple, use the framework the way it is intended, and don't presume to know the 'best' way for the end user's workflow to be shaped.

The additional issue brought up about the rapid obsolescence of the OS and command interpreter is also one that's begging for a good solution: although these software artifacts can be archived and retrieved, if they're dependent on the underlying hardware specifics, at some point you're not going to be able to run it anyway. Dos emulators don't always solve this issue either, or only partly solve it.

> Of course, most of us will be retired or gone so this will be someone else's problem!

Then again, it might come back to haunt you...

In the mid-1980's, worked for a small company that made data collection platforms for environmental monitoring. Many of our customers were government agencies, e.g. NOAA and NWS. One of the guys I worked with was always saying things like "15 years from now, on Jan 1, 2000, all this stuff is going to break."

Fast forward five years. The company had gone belly up and all of us had moved on to other places (both geographically and careerwise...)

Fast forward another 10 years. Autumn 1999. I got a phone call from the aforementioned colleague. "Hey James. Do you remember that geomagnetic project you did for USGS? Well, I've got a contract to verify that it's Y2K compliant and do some other things as well."

We had an archival copy of the source. On 5 1/4" diskettes. In Fastback format.

Step 1 was to find a 5 1/4" diskette drive (I had one squirreled away in my closet.) Then we had to find a copy of the Fastback program. Then we had to find out if Fastback would still work in a Windows environment (miracle of miracles, it did. Another miracle, the diskettes were still readable.) We had to resurrect the build system (which ran under MS-DOS) and see if we could run it under a Command Shell under Windows. And so on. Fortunately, things were still compatible enough that we were able to replicate the original software on the binary level and then we could move forward from there.

I shudder to think about whether any of this work if we got a call to work on this stuff now, in 2015.

As an aside, I am happy to report that the software, as originally written, _was_ Y2K compliant. Because, back in the mid-1980s, I was not going to give my colleague the satisfaction of being right...

Re: "On Discipline" -- You are absolutely correct. Most of my self-induced failures of both vision and implementation have been a result of lack of discipline. Certainly, the military tried hard (and succeeded to some extent) to instill discipline in my life, but I found that once I got out, I did not continue that process as I could have. I did, however, retain the "showing up" part, and that has certainly helped me in my career. Your editorial brings to mind what the writer to the Hebrews wrote in the New Testament: "No discipline seems pleasant at the time, but painful. Later on, however, it produces a harvest of righteousness and peace for those who have been trained by it." (Heb 12:11). My observation has been that many of the problems I have seen in my children have been a result of lack of self-discipline, and some due incorrect or incomplete efforts by my wife and I to discipline (direct their choices) them. All of our children, however, as they reached their late 20's and early 30's told us that they were glad that we DID discipline them -- mainly by putting down and enforcing boundaries in their lives -- after they observed the lives of their peers whose parents made little effort to curb their self-centered behavior.

Writing software/firmware DOES require discipline, both in concept and process, but the results reinforce that choice. For example, I have had issues with some of the MISRA rules, insofar as some of my projects required some relaxing of certain parts, but overall, following those rules has made my code easier to understand (especially for me!), when I come back to it after a period of time.
Your article is a good reminder that nothing worthwhile comes without a cost.

You wrote "In software engineering discipline is even more important than in most other professions. We build intricately complex systems which are invisible; no one can "see under the hood" to get a sense of how well the system was crafted. Other kinds of engineers are held accountable by customers who can see that the system looks like junk. Not so with code."

I humbly disagree. When I download an application or open a web page that takes forever (huge download) and is not responsive (clunky, cumbersome), I can tell that it was cobbled together without looking at the source code. Same thing if I pick up an embedded product (e.g., my eight-channel barbecue grill timer).

Your writeup on discipline is excellent. You really hit the nail on the head. Discipline sums up everything that we push ourselves (and others) to do in engineering.

What is CMMI? Discipline.[1]
What is ISO9001? Discipline.[1]

In the Linux kernel there's no CMMI or ISO9001, but theres a don't-commit-garbage policy, which ultimately is maintainers forcing disciplined development, testing, and submission on contributors.

Discipline in software is the thing that there's no substitute for. It's hard to keep working on code that "works" in order to make it bulletproof, not having or relying on side effects, easy to read, well documented, well architected, and in logically-ordered, easy-to-understand commits with proper commit messages. The hard work (in many respects) comes _after_ you get the code working, and only well-disciplined engineers are willing to do that work. Many engineers don't even understand the benefits of anything after "working," and that's sad.

[1] They intend to force people into disciplined behavior anyway. Whether they work or not is outside the scope of this discussion.