small medium large xlarge

10 Nov 2010, 04:19
Josh Carter (40 posts)

I could use the help of other writers here. I’m trying to figure out an approach to a chapter which attempts to deal with a monstrously huge topic. If you’ve got a few minutes, please review my quandary and toss in your thoughts:

Many thanks, Josh

10 Nov 2010, 05:40
UlrichMerkel (23 posts)

Hi Josh, just flipped through your text and found it deserves a more detailed reading (it’s on my list).

I paraphrase what I picked up (need your feedback if I’m running in the right direction)

IMAGINE a newbie programmer leaves the comfort of his home and enters “the REAL world of programming” There are a lot of pitfalls, dead-end-streets, circle-in-a-spiral waiting to be discovered (The D’oh! of Homer) and mastered.

In a pub near-by some grey-haired (or no-haired) old men staring in their beers telling stories about the time when they were young, left the comfort of their home and entered “the REAL world of programming” and what they encounterd.

The more beer, the higher are the obstacles, but on the other hand, these stories sharpens the eye or our newbie so he may be able to recognise no-go-areas BEFORE the damage is done.

Some similarity with the DON’T PANIC (I published some articles under the roof of “Hitchhikers Guide to the Uniface”), isn’t it. - Describe the situation - wrap it in a nice stroy so it’s easier to remember - give some first-aid-hints - give a decent “further reading”

Think I like this concept.

Success, Uli

P.S. just a first shot, maybe I mixed something with the outline of my work-in-progress

10 Nov 2010, 19:17
UlrichMerkel (23 posts)

After I had a chance to print your text on my customer’s site (as you will see I’m “old school”: started my life with punch-cards, “paper and pencil” for application modeling and testing and all kind of real world hands-on techniques) some annotations:

1) programming happens in the REAL WORLD (!) not in codelines - so tell nice little stories about the problem - enhance this story with common-sense solutions - and find a nice little story so your students will remember your pattern forever

2) use use-cases to bring “the problem” down to real-world stories and SOLVE it there in our every day life, we solve a lot of these “academic problems” with ease - Each morning, Dad, Mom, and 3 children (2 teenagers) battle for resources (bathroom, coffe-machine, pc, …) => this is CONCURRENCY at it’s best

3) Try to use both halfs of the brain (code, abstraction, writing texts all sit in one side) - use pictures, sketches, (if you have some talent: COMICS are best –Dilbert –Simpson,Homer …)

On your “Neutral Data Formats” I think it is very easy to use some TIME WARP (again) in students projects. - just use the behaviour of the ordinaty customer changing his requirements day by day - the routines written on day 1 need some additional parameters on day 4 and do not forget: all the calls scatterd in your application have to be changed to deal with the new signature - on base requirement is to ARCHIVE information (and have it processable for at least 10 years)

so you will SEE that “strong tagging” or good old COBOLs “move corresponding” are ways fighting aging-problems.

Make a simple experiment (once again real-world):

have 3 groups of students develop 3 different questionairs (just 1-page forms) with the same position of data-entry fields, but different labels. Bring just one copy of each form with you plus some cutting knife) => “to reduce costs, no photocopier avail” - we have to turn these forms into overlays by cutting out the fields - “data” is stored on a blank sheet of paper while you re-use the overlay mask => mix the plain data-pages from the 3 groups - interpret the data aginst randomly chosen overlays - enjoy the fun => this should show the benefits of storing data as XMLs, serialised data as key-value pairs etc.

Using the old technique of fables and stories with a morale at the end: Dont use “Actors” in a use-case, but let “real people” act in a user-story

This will make learning, understanding, solving problems much easier. You do not learn how to react in a special problem situation. You learn how to evaluate the problem and react accordingly.

And it will lead you to the mantra “THINK! (first)”

And don’t be afraid using the stand-up-comedians opening: “on my way to this session, I encountered …..” these stories makes your lessons worth attending and “stick” in the memory.

HTH, Success, Uli

10 Nov 2010, 19:19
UlrichMerkel (23 posts)

on previous post, I was hit by the formatter, but I think I found an edit which pleases me as well as the formatter (5 attempts).

13 Nov 2010, 04:05
Bob Cochran (170 posts)


I actually do sit down with new programmers, every now and then. I also sit down with people who claim to be experienced programmers every now and then. And the advice I would give to both sets of people if I’m asked is: become proficient in the technical skills needed at your current employer’s now and in the future, if you wish to remain with the employer over the long term. At my employer, this definitely means learning and using Java and the web technologies that are intermixed with it.

I am not certain if Java uses mutexes or semphores. Sounds C-ish to me. But I think if you wrote a book that skimmed these and other similarly out-of-the-way topics, and pointed the new programmer to further reading if interested, I would buy your book because there is always the chance that I would need to quickly understand what the discussion is about and where the tools are for learning more.

With that said, the single most important ingredient to advancement within the enterprise isn’t really technical skill, it is social skill – the ability to win friends and influence people, as Carnegie wrote. That is what I would tell new people to think about the most. Work most on becoming a useful and well-liked voice within the organization, one who tries to have a proactive influence. And go from there. Advancement isn’t always due to technical wizardry. In fact, the current trend for promoting candidates into front-line management positions and beyond is to look at their people skills, not at their assembly language skills.

And I’d still buy your book!


13 Nov 2010, 05:05
Josh Carter (40 posts)

Thanks guys for taking the time to read my long-winded question and respond. Much appreciated!

@Uli I like the idea of framing topics as use cases!

@Bob The social skills are actually the bulk of my book. I’ve got some parts that are specific to technology, the rest is survival in the corporate / social world. Basically all the stuff I wish I knew for my first couple years on the job. Also, thanks for the encouragement!

15 Nov 2010, 16:28
Jared Richardson (9 posts)

A very quick and light reply… I was taught years ago that if you can’t draw it, you don’t really understand it. When we wrote Ship It!, Andy forced us to draw out the concepts and it was the single most clarifying thing we did. Drawing out the concepts in a clear, concise way will hep you clarify what you’re thinking about. It can also be a road map for a chapter like this. If you absolutely can’t find a way to related the topics, then make them clearly segmented subsections, or even separate chapters.

I’m also a big fan of using mind maps for topics like this. They really help me draw out what I’m thinking about so that I can organize it. The wikipedia page is pretty good, and Andy’s Pragmatic Thinking and Learning delves into them too.

And, as was stated above, create simple examples. It’ll be very difficult to do, because it forces you to boil down everything in your head to something bite sized. Andy H. calls that boiling down the broth. You’ve got tons of great ideas, but you can usually only communicate one at a time. Boil it down, even if it takes days, to a concise, understandable example.

Once you’ve done all that, post it back out on the internet and the world tell you where you missed the boat. :) Then iterate.

15 Nov 2010, 21:52
Josh Carter (40 posts)

Hi Jared, thanks for the feedback. I use mind maps extensively, and I agree they’re tremendously useful for clarifying the content and structure of a topic. When the mind map feels right, the chapter feels right. When one’s a mess, the other is a mess, too.

That said, I’ve mapped these topics a number of times, and I’m still not happy with the writing that’s coming out. The broth is doing a lot of bubbling but it’s still not soup yet. ;)

16 Nov 2010, 04:22
UlrichMerkel (23 posts)

If you have some time (just joking), have a look at and the subpages. It’s a collection of scripts I put together for a community wide framework/core/basics to support community-wide teaching. Success, Uli

21 Nov 2010, 13:02
UlrichMerkel (23 posts)

Stopped writing eat up my days, got my time back to process my inbox etc.

Perhaps a look in may give you some inspiration how your book fits into Dreyfus levels.

I applied this to the current state of “my book” and got some “statement of directions” out of the process.

@all: Think basic theory like this one adds some concrete basement to the books.

Success, Uli

You must be logged in to comment