More about Notepad++: there is a plug-in "SourceCookifier". You can get the outline view of a C/C++ file with this (similar to what we see in an IDE).

There are also a whole lot of other plug-ins that really increase the productivity and make Notepad++ usage a lot of fun.

I was going through the Tools' list and found that there is no mention of GIT version control system. I have used ClearCase over the last 9+ years and switched to SVN about 2 years ago. One thing that I found missing in these two systems is local version management (ClearCase offers this to certain extent). After I started using GIT, this missing part was filled up. Apart from this, GIT offers incredibly fast system (because it is managed locally), a nice UI and complete freedom to do your own changes without affecting others. Another major advantage if GIT is its network independence. You can keep continuing with your work even when you are offline (while in SVN, it is not possible to commit when I am offline). Setting up a repository is pretty easy. There are lots of resources out in the web about GIT and the difference between GIT and other systems. I found this http://ftp.newartisans.com/pub/git.from.bottom.up.pdf a good way to understand GIT. GitExtensions is a UI tool similar to TortoiseSVN (there is also TortoiseGit, but I found it not user friendly).

I was a little concerned about an inaccuracy in one of your readers contributions [which suggested Evernote needs an Internet connection].

This is incorrect. Evernote synchronizes between the local device and the cloud. Only on mobile devices, the synchronization can be set to be "on demand" to reduce storage use.

Evernote is actually an amazing tool/service for managing random data, particularly if you are very mobile. If you'd like me to write a short piece introducing the tool, I would be more than happy to oblige.

I have no business interest in or connection to Evernote Corporation. I am just an enthusiastic user of their products.

Most embedded engineers work for a place that's small (read as, has only 1-3 engineers). No one to split up the work with.

On some occasions I've had folks working for me that wanted to specialize, because they only wanted to do the `fun' work, whatever that was for them personally. The problem is, if they didn't do the other tasks, they didn't learn from the mistakes they made while only doing the "fun" work. Feedback provided was forgotten quickly because they didn't experience the pain of the mistake. The best engineers *can* do it all, and usually still *have* to do it all even after many years, but their key skill becomes a recognized asset for the group, and others with a different key skill can help them in turn.

Specialization is good for the silicon economy, if you consider specialists as elements that can be assembled into teams to make new products and processes. A wider selection of more powerful elements means more options for assembling a multi-element design. But there is an assumed requirement: a lead designer that creates and coordinates the overall design of the product and how the various specialists fit into the picture. Using the Principle of Leaky Abstractions, the lead designer has to understand at least one or more levels of abstraction down from the top level design in order to debug the problems between the design and its assumed requirements, let alone just debugging the design to make it work. Without this knowledgeable leadership, mediocre design results in the best case, and disaster in the worst. Somebody has to lead. The old chestnut of a camel being a horse designed by a committee applies.

I really share your feeling on having a whole project in my hands, from the analysis through development, production support, and tech support. I really love to see things from their conception to practical use, feels
like my work is really "complete", in some sense. Maybe is a Da Vinci syndrome, feeling to master every art and science -- and Da Vinci birthplace is even a few tens of miles from here! But the world has changed from the Renaissance, the notions in a physics textbook can prove it, even though Da Vinci was anyway a genial engineer
(an 'engenial'?).

At the same time, with the new pace of technology, things have become so much more complex from 1980, when I read my first electronics magazine. I think that anyone that can follow a project from the first ideas, to final realization (with success!) is really a lucky person: as I am when I can do the same. You just have to put some limits to your work, because it needs a tradeoff on total complexity. You have to be conscious that it can't go beyond your limited skills (no matter how you grow).

Many years ago I worked with a guy on some heavy mechanics systems, and he was used to say "it's not that we're unable to do it: just isn't in our convenience". This way he was hiding a practical limit, favoring his
enormous self-esteem. We should always keep well grounded (not just electrically), and from there reach for the best we can.

What I fear more, about specialization, is what I read in your words about the lack of reality, that risks to infect even who works in engineering. So, can be fine being specialized in something, but not loosing the bases. Maybe among the bases I should list even the hunger for knowledge, that should pervade anyone who works on applied science. Otherwise, pasting blocks of precooked code, or blindly connecting to a black box, won't be that different from moving boxes of storage.

"A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."

A quote from Lazarus Long, one of Robert Heinlein's in Time Enough For Love.

Regarding your comment on specialization, and while it is true that the industry demands increasingly specialized people, being a generalist is what have kept me on the embedded business for more than 20 years (and counting).

However, I couldn't agree more with your viewpoint and I also think that because of this focus on "saving the company money", it is becoming more difficult for newcomers to get a job unless they are highly specialized.

Anyway, even when extremes are bad, I still think that I prefer to stay at the generalist end of the spectrum.

I'm trying to find an article(s) or book(s) that explains different ways to structure the source code/projects for a common code base used in multiple products across multiple platforms, etc. but haven't found any. I'd like to see more than one approach and the pros and cons of the different approaches. It needs to address things like:

- Differences in target processors

- Differences in features (e.g. feature specific header/API but different implementation for each product)

- Differences in peripherals (e.g. EEPROM API with specific implementations for different chips supported)

- Differences in tool chains (e.g. IAR for target, VC for PC)

- Others?

Can you recommend any good reading in this area?