Hmmm. I couldn't even be bothered to read your example error message, in a thread about error messages. I'm deeply unconvinced that any user will do so.
Someone else had the right answer above - eliminate as many error messages as possible, ignoring likely transient problems (like network outages) until they become critical, and log them somewhere that an admin (or better still, power user) can see and read them when necessary. Alerting the admin or power user via SMS or email is also a good plan. Logging to a database and including stuff like IP address, error class, code etc. such that you can query the results and look for patterns is also a good idea. Those patterns can be used to help you determine what are transient or hardware problems, and what are problems with your UX (and what are bugs!)
Essentially, admit defeat on the error messages, and try to solve a different problem; how do we stop our software getting the way of our user's objectives.
It isn't really the pervasive multithreading that does the job on responsiveness for BeOS, and nor does having the "two threads per window" thing (which I think is what the poster is referring to in terms of "pervasive multithreading) avoid "programmer's tricks" - in fact, you have to be just as careful as if you were developing with Windows, and span up a background thread. One issue for BeOS developers was the amount of hard thinking you had to do to perform simple tasks in a pervasively multi-threaded environment, when you're still having to deal with all the pitfalls of lock-based programming.
However, taking only a few cycles to spin up or kill a thread (rather than the 10,000 plus it takes Windows), or perform a context switch, is a significant help. (There used to be an interesting article benchmarking those things on the Be website, but I can't find it any more).
MS have also added some more interesting stuff to the scheduler in Vista, which helps with uninterrupted sound or movie playback, so at least some of that stuff is possible without a complete redesign.
I entirely agree with this - you should edit your content, then think about layout (plus content tweaks).
This means:
1) Learn to use the outline view in Word to edit your content 2) *Don't* mess with formatting, figures, graphics, charts, twiddly inserts, text styles etc. until you're happy with your body content and outline structure 3) Don't use carriage return or tab between paragraphs. A blank line is a bad line. You're going to deal with paragraph spacing, indentation etc. *when you get to the layout stage*. Consider not using double-spaces between sentences (this isn't so harmful, but still has a tendency to make your layout job harder later) 4) When you've finished with your body text, start working on your layout. Start with section breaks first. 5) *Never* *ever* apply any styles or formatting to the text content directly. Always create a style and apply the style to the appropriate chunk. 6) Think about whether you are styling a run of text, or a paragraph. 7) Don't select text and hit 'italics'. Select text and hit your shortcut key combo for a style you've set up for inline emphasis. You can then change your mind later, and convert all those italics to bold - consistently. 8) When you've finished, go back through and see if there's any Widow and Orphan control that needs tweaking by hand.
If you do this religiously, whatever Word Processor you choose, you'll have a better looking, smaller, easier to deal with document.
I'm sorry if I wasn't clear enough for you. I'll try to make some of my assumptions a little more specific.
I took content to be generally understood to mean 'semantic content' as opposed to 'lexical/wire/machine representation'.
'Based on my interests' as opposed to 'based on the content author's interests, feed organization, source, yes, tealeaves, etc'
'Integration of links' into the semantic model, as opposed to 'a link being embedded in a document for you to click on'
'End-user' as opposed to 'trained software developer / power-user / geek who provides applications and tools to an end-user'
First-class citizen (i.e. seamlessly integrated into the Outlook experience) as opposed to second-class-citizen (out in some external window / app, left to behave differently from the percieved 'main function' of the environment).
I was thinking of something a little more 'automatic' than this. By content, I guess I mean "semantic" query and aggregation. RegEx etc are lexical tools, and, while offering a considerable improvement on the feed organization, don't provide the level of 'smart' organization I'm thinking of.
By 'better integration of links and web content', I guess I mean 'I don't really care that the information has come from an Apache server or an NNTP server, or in my email'. I want my information to be organized by semantic content, author and source (amongst other things) not particularly the transport that got it to me. This means I'm going to want to operate 1 and 2 on any information in my system.
4) has more to do with the developer / power user in me. To be able to build little applets which aggregate this information in a variety of different ways appeals. To be able to do it without getting down-and-dirty with the data interchange, cross-source query etc. would be a godsend.
As an example - say I make a post which has been analysed by the system to be 'question like'. It could then monitor all of the sources to which I am subscribed (and the content to which they link-through) and include appropriately filtered content in some 'remember that question you asked - you may be interested in these' category. One day, it sees that I post a 'positive closure-like' response. It then continues to analyse the feeds based on those semantics, but doesn't present me with the hits any more, unless some of those exhibit 'contradiction' or some level of 'excitement', when it can present those to me in a different 'remember that question you asked last month, well this may be an interesting follow-up for you' kind of way.
I've *no idea* whether this is the kind of thing MS (or anyone else) is thinking of, but that's what I'd like my 'System Of The Future(tm)' to be like.
1) Content-related query and aggregate presentation of feeds, rather than simple 'feed'->'group' organization 2) Intelligent filtering based on my interests (e.g. the kinds of messages I have chosen to read before), not just a simple kill-file / watch mechanism 3) Better integration of links and web content (the kind of thing you're seeing in Outlook 2003 / good RSS aggregators) 4) Tools to help with the end-user integration of threaded news content into other apps (e.g. InfoPath-like tools)
No reason any of these things couldn't be done (beyond the fact that two in particular would require the kind of R&D effort that currently goes in to spam filters - the first half of this sort of equation). Forms of 1, 3 and 4 are already available in Outlook 2003, only it doesn't integrate news feeds into the experience. Hence, I guess, MS stated intention to make news a first class citizen in this world.
Just to give you an anecdotal insight into the jobs market as I see it from a hirers PoV...
In the current economic climate, we've changed our model from hiring permies to commissioning entire projects from contractors. This helps us manage our budget more effectively, and doesn't leave us with the potential millstone of permanent staff should the whole worldwide healthcare industry go pear-shaped in the next 12 months.
This decision makes it damned difficult for new people to break into the marketplace.
However, we'd still consider a newbie if they could demonstrate competence to us, (and perhaps a willingness to be more erm...cost effective...than experienced personnel). For example - 3 months unemployed sounds like a fantastic opportunity to begin to build a portfolio of useful tools and applications - or hang out on the DevelopMentor Java mailing list (or wherever) and do some research, build your skills, get your name known by helping other, even more new-bies out.
In fact, I hate CVs! They are uniformally lousy and uninformative.
That said, the last project I kicked off went to a startup consultancy who happened to mail us a prospectus; a couple of meetings later, they'd got the job, and the guy doing the work is fresh from his Doctorate.
So there is hope - but you've got to think laterally.
Connecting up pre-used, well tested component is arguably the number 1 macro-scale productivity and quality gain. It is also the easiest thing to influence from the sharp-end of development.
If you want to increase the quality of the working day, spend a small portion of your time each day working on architecturally useful refactorings of the existing components, and building automated tests for them (something like JUnit would be useful to you here).
In the sort of application you are working on, designing a workflow framework which encapsulates some of the common busines logic in your system would also improve both productivity and quality.
Have a look at the kind of architecture used in the various workflow and web services tools out there (MS have one called BizTalk server - I'm not suggesting that you use it, just mine it for architectural ideas).
Being a developer often involves upward management of the people around you. This is a skill that is essential if you wamt to keep some degree of control over what you do, and it is not easy to learn.
The best way to manage people (up or down!) is to incentivise them to do what you want. The best way to incentivise them is to get them to _want_ to make the decision your way. The worst way is to threaten them (even if that looks like your best card). They might go your way once, but they will find their own ways of undermining you in future, because being threatened isn't nice!
Management have to present a well reasoned argument for carrying out a paricular task, including a sensible analysis of the risks and benefits. With something technical, it also helps to have a proof-of-concept.
So, devote a very small amount of your time working on some of your architectural ideas, and refactorings, and write up a document illustrating the benefits of what you have done. For example, how much testing time the automated tests have saved versus the time you spent working on building them (don't forget to keep metrics on yourself even if management don't require them - they help enormously when it comes to making accurate estimates!).
If you also balance that documents with an analysis of the risks of rolling out your proposed architectural and procedural changes (and the answer is _never_ that there _are_ no risks!), then you make the manager's decision making process much easier.
It is always more work for yourself in the short term to enact change, but it is usually well worthwhile in the long run (particularly if you are looking to further your career beyond 'code monkey' status, and angle for some architecural position later on).
Slashdot Mirror
Which leads you to wonder why the headline contains the phrase "with the aid of the Conservative Party".
Hmmm. I couldn't even be bothered to read your example error message, in a thread about error messages. I'm deeply unconvinced that any user will do so. Someone else had the right answer above - eliminate as many error messages as possible, ignoring likely transient problems (like network outages) until they become critical, and log them somewhere that an admin (or better still, power user) can see and read them when necessary. Alerting the admin or power user via SMS or email is also a good plan. Logging to a database and including stuff like IP address, error class, code etc. such that you can query the results and look for patterns is also a good idea. Those patterns can be used to help you determine what are transient or hardware problems, and what are problems with your UX (and what are bugs!) Essentially, admit defeat on the error messages, and try to solve a different problem; how do we stop our software getting the way of our user's objectives.
It isn't really the pervasive multithreading that does the job on responsiveness for BeOS, and nor does having the "two threads per window" thing (which I think is what the poster is referring to in terms of "pervasive multithreading) avoid "programmer's tricks" - in fact, you have to be just as careful as if you were developing with Windows, and span up a background thread. One issue for BeOS developers was the amount of hard thinking you had to do to perform simple tasks in a pervasively multi-threaded environment, when you're still having to deal with all the pitfalls of lock-based programming.
However, taking only a few cycles to spin up or kill a thread (rather than the 10,000 plus it takes Windows), or perform a context switch, is a significant help. (There used to be an interesting article benchmarking those things on the Be website, but I can't find it any more).
MS have also added some more interesting stuff to the scheduler in Vista, which helps with uninterrupted sound or movie playback, so at least some of that stuff is possible without a complete redesign.
I entirely agree with this - you should edit your content, then think about layout (plus content tweaks).
This means:
1) Learn to use the outline view in Word to edit your content
2) *Don't* mess with formatting, figures, graphics, charts, twiddly inserts, text styles etc. until you're happy with your body content and outline structure
3) Don't use carriage return or tab between paragraphs. A blank line is a bad line. You're going to deal with paragraph spacing, indentation etc. *when you get to the layout stage*. Consider not using double-spaces between sentences (this isn't so harmful, but still has a tendency to make your layout job harder later)
4) When you've finished with your body text, start working on your layout. Start with section breaks first.
5) *Never* *ever* apply any styles or formatting to the text content directly. Always create a style and apply the style to the appropriate chunk.
6) Think about whether you are styling a run of text, or a paragraph.
7) Don't select text and hit 'italics'. Select text and hit your shortcut key combo for a style you've set up for inline emphasis. You can then change your mind later, and convert all those italics to bold - consistently.
8) When you've finished, go back through and see if there's any Widow and Orphan control that needs tweaking by hand.
If you do this religiously, whatever Word Processor you choose, you'll have a better looking, smaller, easier to deal with document.
'Based on my interests' as opposed to 'based on the content author's interests, feed organization, source, yes, tealeaves, etc'
'Integration of links' into the semantic model, as opposed to 'a link being embedded in a document for you to click on'
'End-user' as opposed to 'trained software developer / power-user / geek who provides applications and tools to an end-user'
First-class citizen (i.e. seamlessly integrated into the Outlook experience) as opposed to second-class-citizen (out in some external window / app, left to behave differently from the percieved 'main function' of the environment).
By 'better integration of links and web content', I guess I mean 'I don't really care that the information has come from an Apache server or an NNTP server, or in my email'. I want my information to be organized by semantic content, author and source (amongst other things) not particularly the transport that got it to me. This means I'm going to want to operate 1 and 2 on any information in my system.
4) has more to do with the developer / power user in me. To be able to build little applets which aggregate this information in a variety of different ways appeals. To be able to do it without getting down-and-dirty with the data interchange, cross-source query etc. would be a godsend.
As an example - say I make a post which has been analysed by the system to be 'question like'. It could then monitor all of the sources to which I am subscribed (and the content to which they link-through) and include appropriately filtered content in some 'remember that question you asked - you may be interested in these' category. One day, it sees that I post a 'positive closure-like' response. It then continues to analyse the feeds based on those semantics, but doesn't present me with the hits any more, unless some of those exhibit 'contradiction' or some level of 'excitement', when it can present those to me in a different 'remember that question you asked last month, well this may be an interesting follow-up for you' kind of way.
I've *no idea* whether this is the kind of thing MS (or anyone else) is thinking of, but that's what I'd like my 'System Of The Future(tm)' to be like.
1) Content-related query and aggregate presentation of feeds, rather than simple 'feed'->'group' organization
2) Intelligent filtering based on my interests (e.g. the kinds of messages I have chosen to read before), not just a simple kill-file / watch mechanism
3) Better integration of links and web content (the kind of thing you're seeing in Outlook 2003 / good RSS aggregators)
4) Tools to help with the end-user integration of threaded news content into other apps (e.g. InfoPath-like tools)
No reason any of these things couldn't be done (beyond the fact that two in particular would require the kind of R&D effort that currently goes in to spam filters - the first half of this sort of equation). Forms of 1, 3 and 4 are already available in Outlook 2003, only it doesn't integrate news feeds into the experience. Hence, I guess, MS stated intention to make news a first class citizen in this world.
Just to give you an anecdotal insight into the jobs market as I see it from a hirers PoV... In the current economic climate, we've changed our model from hiring permies to commissioning entire projects from contractors. This helps us manage our budget more effectively, and doesn't leave us with the potential millstone of permanent staff should the whole worldwide healthcare industry go pear-shaped in the next 12 months. This decision makes it damned difficult for new people to break into the marketplace. However, we'd still consider a newbie if they could demonstrate competence to us, (and perhaps a willingness to be more erm...cost effective...than experienced personnel). For example - 3 months unemployed sounds like a fantastic opportunity to begin to build a portfolio of useful tools and applications - or hang out on the DevelopMentor Java mailing list (or wherever) and do some research, build your skills, get your name known by helping other, even more new-bies out. In fact, I hate CVs! They are uniformally lousy and uninformative. That said, the last project I kicked off went to a startup consultancy who happened to mail us a prospectus; a couple of meetings later, they'd got the job, and the guy doing the work is fresh from his Doctorate. So there is hope - but you've got to think laterally.
Connecting up pre-used, well tested component is arguably the number 1 macro-scale productivity and quality gain. It is also the easiest thing to influence from the sharp-end of development.
If you want to increase the quality of the working day, spend a small portion of your time each day working on architecturally useful refactorings of the existing components, and building automated tests for them (something like JUnit would be useful to you here).
In the sort of application you are working on, designing a workflow framework which encapsulates some of the common busines logic in your system would also improve both productivity and quality.
Have a look at the kind of architecture used in the various workflow and web services tools out there (MS have one called BizTalk server - I'm not suggesting that you use it, just mine it for architectural ideas).
Being a developer often involves upward management of the people around you. This is a skill that is essential if you wamt to keep some degree of control over what you do, and it is not easy to learn.
The best way to manage people (up or down!) is to incentivise them to do what you want. The best way to incentivise them is to get them to _want_ to make the decision your way. The worst way is to threaten them (even if that looks like your best card). They might go your way once, but they will find their own ways of undermining you in future, because being threatened isn't nice!
Management have to present a well reasoned argument for carrying out a paricular task, including a sensible analysis of the risks and benefits. With something technical, it also helps to have a proof-of-concept.
So, devote a very small amount of your time working on some of your architectural ideas, and refactorings, and write up a document illustrating the benefits of what you have done. For example, how much testing time the automated tests have saved versus the time you spent working on building them (don't forget to keep metrics on yourself even if management don't require them - they help enormously when it comes to making accurate estimates!).
If you also balance that documents with an analysis of the risks of rolling out your proposed architectural and procedural changes (and the answer is _never_ that there _are_ no risks!), then you make the manager's decision making process much easier.
It is always more work for yourself in the short term to enact change, but it is usually well worthwhile in the long run (particularly if you are looking to further your career beyond 'code monkey' status, and angle for some architecural position later on).