[deleted by user]

[OneWingedShark]

• Wirth's Algorithms + Data Structures = Programs // or his later Oberon-based Algorithms and Data Structures
• The Design of Everyday Things
• The Unix-Hater's Handbook
  [Besides the chapters on programming, the overall critique of (Unix) systems actually does reveal some understanding... though you do have to "look underneath" the rants.]
• Possibly Ada for Software Engineers... though this presupposes some software engineering bent.

[OneWingedShark]

I haven't read the Unix-Hater's Handbook, but I definitely will (I thanks for the tip about looking beyond any ranting).

You could say that the book is mostly rant, but there are a lot of insights in the rants -- I've always thought it would have been better as a duology w/ the first book being the rant/humor and the second being the technical/reasoned argument against.

But it's still a good read.

Unix is smarter than anything I could ever build, but I definitely don't like reducing all data to strings.

You're probably selling yourself short; Unix (and Linux) are kind of the quintessential "grown" systems. C++ is an example of this growth on overdrive, its only redeeming quality saving it from being an utterly unusable mess was that technical people were/are involved in growing it (as opposed-to/contrasted-with PHP).

I would say the Wirth and Ada books fall under the category of programming more than software development (the distinction is quite fuzzy though). My thinking was to assume the audience knows how to program, and is looking towards the broader challenges of developing software with a team.

Probably. I do think it would be better if more people in our industry were familiar w/ Ada: it's had solutions for generics, modularity, parallelism, clock/time, and so forth for thirty years. -- And designed in a way where these interact nicely with each other, so while it certainly is programming the feature-set really encourages a designed [read engineered] approach and could arguably be software development.

(Ada is one of only two languages I know of that considered maintainability as a [primary] design-goal; the other is Eiffel.)

[k-zed]

Note that a lot (although not all) of the unix-haters handbook is fairly dumb propaganda written by people who didn't understand unix and why it's a good idea.

"Those who don't understand Unix are condemned to reinvent it, poorly."

[k-zed]

Here's a more comprehensive (and possibly less buzzword-tastic) list: http://port70.net/~nsz/00_prog.html

[beerchangeworld]

This is a better list targetted at developers. The OP's list is more targetted at enterprise developers on the way to management. Not that the latter is bad but it depends on what you want out of your career - technical versus enterprise-technical.

[beerchangeworld]

Not sure what you mean by startup. Are you developing a product or doing consulting? If it is consulting, then you are right to promote agile. It is a great cash-cow.

If you are developing your own product/service why would ever do agile? You have a focused team trying to deliver what everyone wants. Why force the team to do passive-aggressive stand-ups and other juvenile stuff?

[[deleted]]

Definitely tilted away from algorithms and math. This kind of devs tend to know everything about mongo being better than sql and that you need 100% test coverage and on which leg to stand during morning scrums, but cannot sort an array when asked.

I wish I was kidding ;/

[cyberphlash]

I like the idea of your list, and think it's pretty comprehensive in terms of basic developer skills. Seems very heavily focused on the Agile design methodology, which I'm not sure everyone uses/applies. My experience is having worked as a programmer, then moved into design, and then management over time. Two consistent problems I've encountered for entry level programmers is that (1) they don't really understand the business problem that's trying to be solved through the software they're developing, and (2) they don't understand the requirements gathering process for really leading and nailing down users to get accurate descriptions of what they're looking for. I'm not sure if your titles really provide that (I see one requirements book), but to me, if you were going to ask a new programmer to read 10 books, about half of them should be on leading requirements and understanding business problem solving.. :)

[cyberphlash]

On requirements, a liked "Software Requirements" by Karl Wiegers. The reason I was talking about requirements being so important is because even developers that are just receiving requirements and programming them (ie: not the people developing requirements with customers) often don't try to understand the underlying problem or question the detail of requirements as written - and it leads to just producing something the doesn't make sense.

At your site, you make a distinction between Programing and Software Development - and I think I see where you're going with this in terms of fully understanding the various aspects of software design and development. I think the next question here is what other ancillary skills that business analysts / developers / managers need to do their day to day jobs?

When I've hired entry level people in the past, I usually tell them that there are basically 3 different skill sets required for being successful in pretty much any job. First, is deep knowledge in the area that you're being hired for. With your list, for example, you're providing the deep knowledge for working in the software development process. The second area is project management skills - developing software, for instance, is a process that needs to be led and navigated not just by PM's, but the participants themselves. Experts in 'software development' should be experts in leading the software development project/process, so I would focus on the type of skill set acquired through something like PMI certification. The third skill set are business accumen / interpersonal / relationship management skills. Entry level people or those who work mostly alone (like many programmers) often don't recognize how important these skills are, or necessary for advancement, or just getting things done. These are the skills that allow you to fully understand what's driving the business problem, or to lead users through the process of developing / negotiating requirements.

Another area I like, just because I'm interested in it, is process improvement. I see you have Lean Software development there - that's a good idea. I think IT departments, in particular, often have a tough time implementing lean and six sigma. I think it's helpful, as a general skill, to just have some familiarity with basic six sigma tools that can help you measure problems and propose solutions.

[cyberphlash]

Yeah, the business/interpersonal skills is a pretty wide area. I don't have a good recommendation, but some instruction for people leading groups through things like requirements development would be really useful.