I mentioned my use of a favorite editor and command
line scripts; so, I should add some detail on those
two:
My favorite editor is KEdit (Mansfield Software), a
PC version of the IBM VM/CMS editor XEDIT. The
macro language of XEDIT is Cowlishaw's Rexx, and
KEdit uses their similar Kexx. My scripting
language is ObjectRexx, an extension of Cowlishaw's
Rexx. Rexx is elegant.
Nearly all my typing for everything goes into KEdit
-- one means of input to rule them all.
My spell checker is Aspell from some TeX
distributions; it's a darned well written program,
can support several languages, and lets me maintain
just one addendum dictionary!
VB:
I programmed in C for a while and got used to it.
If I used C# daily, then I'd likely get used to it.
As I recall, K&R confessed that the C syntax is
idiosyncratic, which I agree with. E.g., can write
i = j++ + ++k
Too tricky for me. When I read Lippman on C++, it
seemed trickier. What I've seen of C#, say, from
reading Microsoft's Web pages at their MSDN, it
looks like it's borrowed such 'sparse' syntax from
C++.
So far it appears that Visual Basic .NET (VB) and C#
differ essentially in the flavors of 'syntactic
sugar' and could be translated one to the other,
almost statement by statement. So, I prefer VB
mostly due to a flavor of syntactic sugar.
What I like in the VB syntax is essentially the
"cumbersome" part -- somewhat redundant, easy to
read, puzzle problem free. I type the code in
quickly and let the VB compiler tell me when I've
omitted little things. But there's enough
redundancy in the syntax so that the VB messages
usually still recognize what I intended. Good -- I
don't want some tiny typing errors to convert what I
want into a still legal statement I don't want.
VS:
First, I don't like the one window with lots of
small panes. Second, when I look at VS, I can't
make any sense out of it. E.g., I have no idea what
the little icons or the various panes are for.
Then, I've never seen any very good documentation.
I could figure it out, but my objective is my
business.
The times I tried VS; it created a 'project' where
Hello World started off as 50 MB of 'stuff' I didn't
understand. Then I fear that if, really when,
something goes wrong I will have to dig into that 50
MB, with no documentation.
For more, I don't want to type into VS if only
because I don't see any hope for the kinds of
functionality I get with KEdit and macros that I
highly value.
Instead of VS, here's an outline of what I do:
In the morning when I start programming on my Web
2.0 project, I run some little ObjectRexx scripts
that open about 25 windows, mostly KEdit and
Firefox, in a particular Z-order and arrange the UL
corners of the windows equally spaced on a line on
my screen from LL to UR while preserving the
Z-order. I close the windows I won't be using that
day and end up with 10-20 windows. When the windows
get to be a mess, one click on an icon drives an
ObjectRexx script to arrange the windows again
preserving both the Z-order and the order of the
left sides. Net, I get in effect much more screen
area for my work than I get from the one VS window
with its small panels.
The windows are mostly for files and directories
where I am working or with relevant documentation.
In addition, one of the scripts starts in a console
window the session state store I wrote (some TCP/IP
and a collection class).
I have 4000+ Web pages of documentation and a little
system for abstracting the pages and finding the
pages I need. In addition, for more relevant pages,
I put in my source code page titles and
corresponding tree names on my computer; then one
keystroke in KEdit has Firefox display the Web page
from which I can continue to traverse the MSDN tree
back at MSDN. That's my substitute for
Intellisense.
KEdit is terrific as an easily automated chef's
knife and cutting board for slicing and dicing files
of text, working with collections of files, starting
programs, dialing phone numbers, etc. I don't want
to type into VS instead of KEdit.
For debugging, the main challenge for me is finding
the cause of the software going "poof" after running
for some interval. So, with interactive debugging,
there is too much stopping at break points and
starting again. Instead, I just have my code write
values of relevant variables to a file or, for the
code for a Web page, the Web site log. After "poof"
I look at the output, maybe 10 MB, go the bottom
where the "poof" happened, and move backwards, using
the KEdit 'select' tools to show me what I want.
It's always worked so far! Sure, later I could have
the writing go over TCP/IP to a program that keeps,
say, the 10,000 most recent lines.
> You don't use version control, bug tracking,
feature planning, nightly builds, continuous
integration...any of those? I would think a project
without those essentials would be quite
disorganized.
Sure, some of those I do now. But I just don't yet
have or need formal procedures and tools.
One thing I do nightly is an incremental backup!
Since I'm just one guy, some simple techniques are
sufficient for being organized. And at Yorktown
Heights, I found that for our team of seven, still
we could use just simple techniques.
> These requirements sound extremely high. Wouldn't
someone with a recent B.S. in computer science or
software engineering be significantly more prepared
for the job (as well as less expensive to employ)?
I just said "sufficient"; I didn't say necessary or
"requirements"!
One reason for my interests in this thread is that I
don't yet know just how I will hire; I don't intend
to hire all Ph.D.s.
My company needs for the code to be a solid company
'asset'. So, the code has to be well written and
not just some gibberish.
For what I'm doing, I believe I could teach good
people quickly.
On my
"I begin to conclude that software is still a
relatively simple subject"
So, have (n)log(n) in-place sorting, balanced binary
trees, TCP/IP, if-then-else, do-while, call-return,
etc. Simple.
We are in agreement. Most of the sauces in
Escoffier are fairly simple, but running a three
star Michelin restaurant is not. Having a big
chunk of production software in good shape and
working and moving along nicely is not so easy and
takes some good people.
On salary we may not be communicating: What I hear
about programmer salaries, e.g., people happy to get
$100 K a year, sounds a bit short of the standard I
mentioned. E.g., $100 K a year won't go very far
where houses are $400 K, taxes are high, and want to
support a wife and three kids.
Early in my career, in one two week period I went on
seven interviews and got five offers. Then I was
getting paid about six times what a new Camaro cost.
Today that would work out as $240-300 K per year.
Right, houses at $400 K are too expensive for anyone
to afford. Yet, people keep buying them.
We largely agree on training. Some conferences are
just for entertainment, but some are important for
training. And could at times use some in-house
lectures or short courses, given by people from
inside or outside.
> This seems like a very bad approach to use if you
value improving your skills, gaining domain
knowledge, or keeping up with industry trends.
I'm not interested in JavaScript because I don't
have anything important in mind I need to do with it
beyond the JavaScript Microsoft writes for me.
I believe that the goals of both the company and the
employees are closer to the bottom line, that is,
the real business needs, than what you mentioned.
And I believe that there is relevant knowledge to be
gained much more valuable than what you listed. To
me "industry trends" are too much like a fashion
show, not that I've ever been to one.
We're not communicating well on the role of good
technical writing. E.g., suppose someone in my
server farm looks into system management platforms
from, say, CA, EMC, HP, IBM, and Microsoft, goes to
some conferences, tours some sites, gets some sales
pitches, talks to some consultants, etc. Then I
will want them to write up a report on what they
learned and give a presentation to likely the whole
server farm staff, myself, and maybe others.
I could list another dozen such.
For a significant new software development project,
there should be at least a first cut design
document.
For technical writing, I believe that should be done
by people who understand the material really well.
For 'technical writers', they may help such a person
with organization, grammar, punctuation, building an
index, etc.
Your remarks critical of "JIT skills" have some
value. But I anticipate people bright enough and
growth slow enough that what I outlined should work.
If they want to know how the Web works, say, from
the ISP connection into the LAN switch to the
servers, etc., fine: I'll outline it quickly. Then
I'll have the first person write up notes available
to teach others, get some books, etc.
Current computing can be super complicated, but my
plans for my company are to keep nearly all the
computing relatively simple. If the computing gets
to be a big, complicated thing, then I've done
something wrong in my business planning and server
farm and software architecture.