Re: PPIG discuss: Programmer education ain't what it used to be
On 15 Jan 2008, at 15:02, Lindsay Marshall wrote: Based on the discussion I listened to, the statement that applicants equate enrolling on this program = becoming great at Java = well-paid employment is not true here, as Michael suspected. No, there it is applicants equate enrolling on this program = get degree from cambridge, even a 3rd = well-paid employment I'll provide a datapoint without the cachet of Cambridge, then -- In 1998, the University of Queensland chose Java as a teaching language. Although I wasn't directly involved in the decision, I did observe it taking place. There had been a tension between the electrical engineering department's desire to teach C early in the course (because students were expected to use it in the microcontroller practicals) with the CS department's concerns that C promotes bad habits when taught as a first or second language because it makes it too easy to do unsafe pointer arithmetic (so instead the CS department had taught engineers Pascal and Modula2, which they could not use in practicals due to poor compiler and tool support on the relevant microcontrollers). When the departments merged, Java was adopted because it was a strongly-typed language with a good OO model and C-like syntax -- this hit both bases of teaching good habits and reducing the learning barrier to using C in embedded practicals. Again, there was no applicants equate enrolling on this program = becoming great at Java = well-paid employment process involved. William Billingsley -- PPIG Discuss List (discuss@ppig.org) Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss Announce admin: http://limitlessmail.net/mailman/listinfo/announce PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
Re: PPIG discuss: Documentation for large systems
So theoretically, 20% of the team have just gone through this learning process. What did they misunderstand? What questions were they asking their mentors and why. Ask if you can read the notes they made, and interview them about those notes -- which bits actually turned out to be useful and which were blind alleys? Hopefully, that'll quite quickly tell you what level they are getting stuck at -- whether they have difficulty getting the big picture, or whether there are specific details that are missing -- whether it's a navigational problem or an understanding problem, etc. (I'm hoping 20% of the team doesn't just mean 1 additional new grad, but that you might get a breadth of responses) regards, Will. On 7 Nov 2007, at 14:23, Ruven E Brooks wrote: Let me elaborate a bit on my original request. 1. I'm assuming that most or all of the previous developers/ architects of the system are unavailable. All that's left are the artifacts, code plus whatever else. There's no one to talk to about where to start, etc. or about the overall structure. 2. Imagine that, instead of being a new chief architect, that the plan is to replace 20% of the developers on the project every year but not to increase staffing levels by 20% (which is what would be required with the current methods of getting people up to speed.) 3. I didn't rule out active discovery of content. In fact, that's what people do today in our organization; they look at the code and analyze the code, using tools of varying degrees of sophistication. The problem is, it's terribly time consuming, and the same discovery process has to be repeated by each new team member; that's what takes the 6-12 months - active discovery of content. I'd like to jump start or shortcut the process. [I note that In educational theory, active learning doesn't mean that you put the students on a desert island and expect them to actively discover particle physics; it means that you carefully set up situations in which the students participate that enable them to learn. I can think of equivalents for learning a large piece of software, but developing them requires even more work than writing the 20 page document.] Ruven
Re: PPIG discuss: Documentation for large systems
Ruven, I'm a man with a hammer, so I'm interested in finding out whether your problem might be a nail... From the issue you've described (it's difficult to know where to start and what to read), it sounds like the shortage is not in the detailed documentation per se, but in an introductory guide to the purpose and parts of the system -- a textbook for working with the system. The hammer that I have is a better system for authors and students to collaboratively write textbooks. Someone who used to work with SAP recently suggested to me that because of the particular way it works, the textbook system could be very useful to programmers and configurers for large systems. (Who often find the documentation written by the experts to be too detailed and low-level to navigate effectively.) Anyway, I'm interested in finding out how well the technology fits into that of market (if at all), so I'd love to hear more about the issues you and your team are facing, if you're willing to chat more about it. best regards, Will Billingsley Research Associate, Centre for Applied Research in Educational Technology, Cambridge University On 6 Nov 2007, at 16:56, Ruven E Brooks wrote: [EMAIL PROTECTED] wrote on 11/06/2007 10:21:14 AM: Who will be the reader of these documents? If the readers are going to be software developers working on the source do you think the exercise will be cost effective? After all, if there are only going to be a few readers and they are only going to read parts of the source (ie, on an as needed basis) then you documenting all of it may be more costly. It takes a minimum of six months and, more typically, a year, before developers joining this project have positive productivity, e.g. the value of their efforts exceeds the cost in other people's time to bring them up to speed. From informal discussions, this length of time is typical, or, perhaps, on the speedy side for applications of this size. If you assume that four or five developers on the team are being replaced per year, and that better information could cut the one year learning time down to six months, then we have something like 2.5 person years, every year, to invest in getting and updating the information. The problems with just reading parts of the source, which is what happens now, are that it's often difficult to know where to start and what to read. A large part of the 6-12 month learning period is spend building up enough of understand of the overall structure so that know where to focus detailed understanding. Ruven
Re: PPIG discuss: Loop Bounds and Errors
Frank Wales wrote: On 01/31/2006 02:37 PM, Howie Goodell wrote: The test ilimit fails where 16-bit math or huge loops hit the signed-arithmetic threshold. Using unsigned arithmetic only buys you another power of 2. The safe approach is to say, limit-i1. Oh, sure. I just didn't want to complexificate the example by introducing issues of machine representation and wraparound, let alone handling signalling NaNs or sign extension. I couldn't resist mentioning this... Curiously we have here an example of how it can sometimes be safer to use the common approach. In Howie's refining the ilimit test to come up with a safer alternative, he inadvertantly put limit-i1 which is mathematically not the same -- I assume he meant limit - i 0. Frank's second pair of eyes didn't pick the error up and readily agreed with it. So the new checked safer approach would not run at all if the limit was, say, 7 and would go whistling off to the signed-wraparound-point if limit was 0; while the common approach stands a reasonable chance of working most of the time. Using the common approach might someimes be safer because perhaps your code-reviewers might be more likely to spot your mistakes if you aren't forever doing things in uncommon ways. ...ok, back to work. -- PPIG Discuss List (discuss@ppig.org) Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss Announce admin: http://limitlessmail.net/mailman/listinfo/announce PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
