Some professional notes
- If I am not for myself, who is for me?
When I am for myself, what am I?
If not now, when?
– Hillel (circa 70 B.C. – 10 A.D.) - If I do not document my results, who will?
If the significance of my work is not communicated to others, what am I?
If not now, when?
– philg
- do remember that if Microsoft, Oracle, Red Hat, or Sun products either worked simply or simply worked, half of the people in the information technology industry would be out of jobs.
- A comment header at the top of every source code file and an email address at the bottom of every page. That’s a good start toward building a professional reputation. But it isn’t enough. For every computer application that you build, you ought to prepare an overview document. This will be a single HTML page containing linear text that can be read simply by scrolling, i.e., the reader need not follow any hyperlinks in order to understand your achievement. It is probably reasonable to expect that you can hold the average person’s attention for four or five screens worth of text and illustrations. What to include in the overview illustrations? In-line images of Web or mobile browser screens that display the application’s capabilities. If the application supports a complex workflow, perhaps a graphic showing all the states and transitions.
- keep in mind that for every person reading this chapter a poor villager in India is learning SQL and Java. A big salary can evaporate quickly. Between March 2001 and April 2004 roughly 400,000 American jobs in information technology were eliminated. Many of those who had coded Java in obscurity ended up as cab drivers or greeters at Walmart. A personal professional reputation, by contrast, is a bit harder to build than the big salary but also harder to lose. If you don’t invest some time in writing (prose, not code), however, you’ll never have any reputation outside your immediate circle of colleagues, who themselves may end up working at McDonald’s and be unable to help you get an engineering job during a recession.
- Professional Definition:
- they practice at the state of the art, writing computer programs that are used by millions of people worldwide (the GNU set of Unix tools and the Linux kernel)
- they have innovated; Stallman having developed the Emacs text editor (one of the first multi-window systems) and Torvalds having developed a new method for coordinating development worldwide
- they have taught others how to practice their innovation by releasing their work as open-source software and by writing documentation
- Professional 7 Objectives:
- 1- a professional programmer picks a worthwhile problem to attack; we are engineers, not scientists, and therefore should attempt solutions that will solve real user problems.
- 2- a professional programmer has a dedication to the end-user experience; most computer applications built these days are Internet applications built by small teams and hence it is now possible for an individual programmer to ensure that end users aren’t confused or frustrated (in the case of a programmer working on a tool for other programmers, the goal is defined to be “dedication to ease of use by the recipient programmer”).
- 3- a professional programmer does high quality work; we preserve the dedication to good system design, maintainability, and documentation, that constituted pride of craftsmanship.
- 4- a professional programmer innovates; information systems are not good enough, the users are entitled to better, and it is our job to build better systems.
- 5- a professional programmer teaches by example; open-source is the one true path for a professional software engineer.
- 6- a professional programmer teaches by documentation; writing is hard but the best software documentation has always been written by programmers who were willing to make an extra effort.
- 7- a professional programmer teaches face-to-face; we’ve not found a substitute for face-to-face interaction so a software engineering professional should teach fellow workers via code review, teach short overview lectures to large audiences, and help teach multi-week courses.
- Presentation Format:
- 1-elevator pitch, a 30-second explanation of what problem has been solved and why the system is better than existing mechanisms available to people
- 2-demo of the completed system (see the “Content Management” chapter for some tips on making crisp demonstrations of multi-user applications) (5 minutes; make it clear whether or not the system has been publicly launched or not)
- 3-a slide showing system architecture and what components were used to build the system (1 minute)
- 4-discussion of the toughest technical challenges faced during the project and how they were addressed (2 minutes; possibly additional slides)
- 5-tour of documentation (2 minutes) — you want to convince the audience that there is enough for long-term maintenance
- 6-the future (1 minute) — what are the next milestones? Who is carrying on the work?
- Panelists love documentation.
- Panelists need to have the rationale for the application clearly explained at the beginning.
- Decision-makers who are also good technologists like to have the scale of the challenge quantified.
- You need to distinguish your application from packaged software and other systems that the panelists expect are easily available.
- If at any time during a pitch someone points out that there is a Microsoft product that solves the same problem, the meeting is over.
- At the same time, unless you’re being totally innovative, a good place to start is by framing your achievement in terms of something that the audience is already familiar with, e.g., Yahoo! Groups or generic online community toolkits and then talk about what is different.
- Decision-makers often bring senior engineers with them to attend presentations, and these folks can get stuck on personal leitmotifs.
Resource:
1 – http://philip.greenspun.com/seia/writeup?
