Maggie++

I wonder when this trend of developers thinking it is not their responsibility to test their code started.

I started writing a response in agreement with Writing unit tests is your job so quit making excuses, when I realized I should blog instead.

In the 80s when first starting to write in a higher level language for production code, we were required to write unit tests. Using C was the first chance we had of running our code off of the hardware without using emulation software - it was so much easier when we could run tests at our desks. It was a very welcomed addition to our jobs.

Testing assembly code was time-consuming and extremely tedious (though I did love doing it) which made it a huge expense. I enjoyed patching the code in the lab as I tested (yes I know, I am a geek), but it was difficult to keep track of those patches and update the source later. Once the source was changed, compiled, copied to tape, and put onto the hardware – of course this was after scheduling time in the lab to do so – it had to be re-tested.

After your code was tested and did what you expected it to do, came integration testing. This was very similar but not a solo task and was performed with coworkers to see if your code actually worked with their code. Again this was an expensive part of development.

QA’s function was to ensure the code did what it was supposed to, not to see if it did what you thought it should do.It was not their job to neither find coding bugs nor trap exceptions.

Today it still isn’t their job, QA has their hand’s full doing validation and verification and all sorts of regression testing and analysis among other things. The last thing they need to spend their time doing is developer testing, i.e. finding code and integration bugs.

Once QA enters the picture, the need comes to enter and track all issues. This brings unnecessary work to QA and unnecessary work for developers as the need to triage the bugs, fix the code, document the fix and have QA retest.

Coding and testing are so much easier today – we have automated test runners and special api syntax for expressing our tests. It still amazes me how easy it is to use a test tool to call into a function without having to figure out the steps to get there from higher up the code tree.

It is a developer’s job to test their code. Untested code should never be committed into a centralized version control system (if using dvcs then of course you should and would – but that’s another topic). Doing so will cause your teammates to waste their time catching and fixing your bugs, making it harder for them to get their own job done.

Once when new to a project I asked my co-worker what we was used to test the code. I figured he would give me the name of a test framework. I was taken aback when he told me – oh, we don’t have to test our code; we have a great offshore QA team that will find all of the bugs. Well I wrote tests anyway – and yes the fantastic QA group found bugs – but they were not code related. These bugs all pointed to places where I had misunderstood a requirement or a requirement was unstated or not thought of. And I needed QA to help me solve them.

There is a concept I got long ago from a parenting tape* that one should not ‘make work’ for themselves or others. I taught my kids this when they were little. If you have a spill and don’t clean it up or put something in a place where it doesn’t belong, you have made ‘make work’. Make-work is unnecessary work that wastes someone’s time, even your own. The spill will be harder to clean after setting there and you will need to run around the house putting everything in its rightful place.

No testing will not make your code perfect, nor does it need to. However it will save everyone time and help your project to be successful. So please do not make-work. Better yet poka-yoke your code.

maggie++

*Possibly from one of Barbara Coloroso's  parenting tapes or talks. 

There has been much talk lately about developing software, learning software, skill levels, drag and drop demos and what is Microsoft’s responsibility to the .Net community.

I don’t think Microsoft is responsible for developers’ knowledge or programming skill level. They create tools that can be used for development. That is all we need from them. There are other tools and languages to use and there will be many more in the future.

I think some of the responsibility of quality software development lies with the companies that hire developers for development. You get what you pay for. Companies need to hire talent and provide resources for those developers to continue to learn. Software evolves as does other technologies. Continuous Improvement is not just a buzz word. It does not happen on its own; it takes leadership. It is also vital for the software community to take responsibility for building a better community.

If a developer writes an application by drag and drop that produces code that is un maintainable who is at fault? Have they been taught another way? Are there expectations of design for maintainability? Have they ever had to maintain code another has written? Should Microsoft have warned them in a sales demo that that it might not be the best way to write code? Has someone reviewed the code and the design? Have they been provided the necessary resources to perform their job? Do they have someone to ask how to make it better?

Writing good software is hard. It is not a job for beginners. Microsoft provides the languages, compilers and tools used to write .Net code. If a developer does not know how to write code and isn’t being taught how to do it better they are not really developing software and they certainly aren’t going to become expert or master at their craft.

Anyone can throw flour, salt, sugar , yeast and water into a pan and put it in an oven. It will not become bread unless they followed a good process and knew what it takes to make a good loaf of bread. Often they will have been taught by someone else to bake bread or they will have spent considerable time experimenting until they get it right. They do not go to the appliance store for a salesperson to demonstrate the oven’s new and shiny features to make better bread.

We are becoming a more drag and drop society. I can throw a frozen bag of vegetables into the microwave push a button and have hot steaming vegetables to serve. I did not have to select quality vegetables from the store. I did not need to know how to wash them or that I should and why. I did not have to know how to trim them and prepare them for cooking. I didn’t even need to get a pan dirty.

Software has not reached this level of maturity. I need to understand the details and syntax of the programming language. I need to know how to interface with the operating system. I need to know what the operating system is capable of. I need to know what functions the framework provides and how to make good use of them. I need to understand how to communicate with all other software I need to interact with. I need to know all of this in addition to learning the application domain and what the software is supposed to do.

Software development techniques do need to mature – it should be easier to put a system together. We should not have to spend so much time reinventing the wheel and writing plumbing code. There needs to be a better way to find out what components are available and when they should be used. If we need to buy controls from several different venders to build the best software in an efficient and timely manner then we should be able to and given a means to do so.

My husband is an RF design engineer. He designs all sorts of radio devices and components that go into larger systems. If he had to design every chip, filter and capacitor anew for each project he would not get anything built. He spends considerable time modeling the interaction of these parts on the computer before he decides what will go on the boards and how they should be arranged. He then builds up a prototype and tests it’s functionality. Often things do not work they way they should; there are stray signals and what not (not my domain to explain well) interfering with the functionality. It is a highly iterative process – he goes back and forth between modeling and design and testing in the lab many many times to get it right. He tries many parts out; some are rejected – sometimes they do not make the specs they are designed for in the environment he places them in. Is this the fault of the part designer? No, they can’t possibly imagine every situation where their parts may end up. It just means he needs to change the design to make the part work or find a new part.

He has spent dozens of years becoming an expert in his field. He had mentors from the very beginning guiding him. He cooped during college to get vital real-world experience. He now makes sure to bring in coops to work with him as he knows this is how good engineers will be grown. Yes it takes time away from his work but it is important. He knows that they will not learn in school all that they will need to be successful. He does not expect an engineer with just a few years experience to be able to produce a good product on their own. It takes time to nurture and develop talent.

What will the software community do to find, nurture and develop talent?

Maggie++

The Central Ohio Day of .Net is approaching. The organizers are busy choosing speakers and making plans. Submit a talk by March 2 if you have something to share. Be on the look out for registration to open next month and sign up quickly as I’m sure it will fill up fast.

This is an event you will not want to miss. The day is all about community, learning and new ideas. 2008’s event changed my life.  I  had been to numerous code camps in the area and had been a regular attendee of the Cincinnati .Net Users Group.  But I pretty much kept to my self and talked to the few people I knew at the time. 

Here is a summary of the sessions I attended last year along with links to the slide decks for more information. 

I first sat in Joe O’Brien’s talk on Why Ruby and initially felt left out because everyone in the room seemed to know each other, they were twittering and many made big deals (jokingly) about having Macs at a .Net event.  [aside:  I do not understand all of the mac / pc sparring, browser wars and fights over who’s text editor is the best thing since sliced bread.  Lighten up, they are all just tools, it’s the brains that matter ;)]  That faded away as Joe sparked my interest in Ruby.  I had been introduced to Ruby by Jim Weirich several years prior at the Cincinnati Programmers Guild.  At that time it looked like a fun scripting language to easily make tools.  Now Joe was showing how much Ruby had grown and you could build all sorts of things including web applications. He even started his own company to develop Ruby applications and more.

F# It! was presented by Amanda Laucher and James Bender.  Amanda explained twitter so that “I got it” [I signed up later that day and Amanda was the first one I followed]  Then she and James introduced me to functional languages and F#.  I was fascinated and quickly shared their enthusiasm for this ‘new’ way of thinking.

Intro to Boo and DSL by Jay Wren introduced me to domain specific languages.  Intro to WCF by Dan Rigsby and Reliable Messaging in WCF by James Bender provided good insight into what WCF is and how I might use it.  The day ended up with Well, Isn't that Spatial by Jason Follas which introduced location data enhancements to  SQL Server 2008.

Last year at the CODODN is when I was first exposed to Twitter and I became part of the Twitter Tribe.  Since then I have attended similar events in OH, TN, TN, KY, IN and OH.  Each time I expand my learning about software development and my network of fellow developers.  As a result I have greatly expanded the blogs I read, the podcasts I listen to and the books that I read.  I even started my own blog. I have also come out of my shell and go out of my way to talk to and meet other consultants at work and have become more connected to the developers at the local .Net Users Group.

I am anticipating a diverse set of sessions to choose from on April 18th and am looking forward to seeing old friends and making new ones.

maggie++

CodeMash  will be in three short weeks. Tomorrow (12/17/2008) is the last day to reserve rooms with the discount rate  at the Kalahari resort.  If you have not registered, what is holding you back?

The session details have been posted and I have tried to plan out which talks I may attend.  This is proving to be very difficult.  If I were Hermione I would be able to wear a Time-Turner to get the most from CodeMash. Hermione Granger is a classmate of Harry Potter.  During the third school year at Hogwarts, Hermione uses a Time-Turner to set time back an hour so she can attend simultaneous classes and maximize her learning.  A Time-Turner is a magical device invented by J. K. Rowling for the book Harry Potter and the Prisoner of Azkaban.

If I were Hermione then I would use this time travel device to attend simultaneous sessions at CodeMash.  Here is the list of CodeMash sessions as they stand today.  I have highlighted the sessions I am most likely to attend.  I would also like to be able to attend all of the Open Space sessions as I know much valuable discussion will take place. Time travel would certainly make it easier to choose sessions, but would probably be exhausting as well.

What strategies are you going to use to get the most out of CodeMash? 

Wednesday:

Full-Day
CodeJam: Gary Bernhardt, Sarah Dutkiewicz, Joe Fiorini, Corey Haines, John Stockton
.NET 101 With Jeff Blankenburg and Josh Holmes
Java, Groovy, and Grails 101

AM
iPhone Development 101
Test-driven Development 101 With Leon Gersing
Turning the Ship With Dave Donaldson

PM
Kanban 101
iPhone Development 101
Test-driven Development 101 With Phil Japikse
Value Stream Mapping Workshop With Mary Poppendieck

Thursday

8:15am to 9:30am
KEYNOTE #1: Eric Meyer: JavaScript Will Save Us All

9:45am to 10:45am
Dynamic Hyper-Video in Silverlight (Jesse Liberty)
Introducing Agile for Real World Programmers (Greg Huber)
Programming in Scala (Venkat Subramanian)
Introducing the iPhone SDK (Chris Adamson)
Introducing the Live Mesh SDK (Jeff Blankenburg)
Adobe Flex Fundamentals (TBA)

11am to 12pm
Re-thinking UI: WPF Data Templates (Carey Payette)
Three Tips to Improve Your Dev Process (Jim Holmes)
Introducing Prototype and Scriptaculous (Leon Gersing)
Developing JoeMetric for the iPhone (Joe O'Brien)
Pumping Iron into Python: Intro to FePy (Sarah Dutkiewicz)
Developing for the Microsoft Surface (Jennifer Marsman)
Dynamic Languages and the JVM (Nathaniel Schutta)

12:15pm to 1:30pm
LUNCH + KEYNOTE #2: Venkat Subramanian: Pointy-Haired Bosses and Pragmatic Programmers—Facts and Fallacies of Everyday Software Development

1:45pm to 2:45pm
Scaling Habits of ASP.NET Applications (Richard Campbell)
Thrashing (Mary Poppendieck)
Erlang: The Basics (Kevin Smith)
Groovy/Grails for non-Java Developers (Mike Kimsal)
Python Data Visualization and Imaging (Zach Steindler)
Well, Isn't that Spatial (SQL Server Spatial Data) (Jason Follas)
Adobe Flex with MVC Frameworks (Robert O'Malley)

3:35pm to 4:35pm
Demystifying Windows Communications Foundation (Keith Elder)
Soft Skillz (Brian Prince)
Managed Extensibility Framework (Drew Robbins)
IPhone Web Development with Grails (Chris Judd)
Practical Scala (Dianne Marsh)
What? Threads Are Hard? (Jim Weirich)
Functional Concepts for OOP Developers (Bryan Weber)

4:50pm to 5:50pm
Modeling Types with Extension Methods (Bill Wagner)
CI: More than just a toolset (Jay Harris)
Griffon in Front, Grails in Back (Jim Shingler)
Ruby Desktop Application Framework (Lance Carlson)
Microsoft Virtual Earth, Now in 3D! (Aydin Akcasu)
Drupal at Zattoo: A Case Study (Chris Cassell)

Friday
8:15am to 9:30am
KEYNOTE #3: Mads Torgersen: One Big Happy Family – Where are the Managed .NET Programming Languages Heading?

9:45am to 10:45am
Dev Guide: Skinning Silverlight Controls (Jesse Liberty)
Practices of an Agile Developer (Venkat Subramanian)
Grease, a Parallel Systems Architecture (Vielmetti)
Testing Rails (Joe O'Brien)
JVM Scripting with Jython (Mark Ramm)
Test Infecting the Legacy Organization (Nathaniel Schutta)
IronRuby in the Real World (Michael Letterle)

11am to 12pm
Guerilla SOA for WCF (Joshua Graham)
Language-Oriented DDD (David Laribee)
Networking and Communications in Silverlight (John Stockton)
Cool Stuff with Computer Vision (Scott Preston)
Rich Apps with Groovy Swingbuilder (Andres Almiray)

1:45pm to 2:45pm
Deep LINQ: C# Query Expression Pattern (Bill Wagner)
Improving Web Application Performance and Stability (Steve Smith)
Spring 2.5 MVC (Ken Sipe)
Actor Concurrency (Alex Miller)
Introducing BazaarNG (Mike Woelmer and Jay Wren)
A Look Inside Microsoft Labs: Photosynth, Deep Zoom, Live Mesh, and More (Jeff Blankenburg)
A Programmer's Guide to User Experience (Josh Walsh)

3:30pm to 4:30pm
Multi-threading Mojo with F# (Dustin Campbell)
Executable Documentation with easyb (Andrew Glover)
Cloud Computing with .NET (Wesley Faler)
Modern Web Applications with .NET (Drew Robbins)
Ruby Isn't Just About Rails (Adam Wiggins)
Reverse Engineering Applications (Joe Kuemerle)

maggie++

There are several posts (e.g. Joel’s here and Jeremy’s here) about the new SharePoint Master Certification and the debate over it reinforces my decision to stop pursuing SharePoint at the present time. 

So, this blog post is about my brief dive into all that is SharePoint.  A little history:  I became a consultant early last year and one focus was going to be learning SharePoint.  I ended up being assigned to a C++ unmanaged project (a whole different story) and dove into learning C++, MFC, ATL and COM instead.

When I became ATO (at-the office or on-the-bench) this summer, I took the time to pick up SharePoint.  I began attending all of the sessions (at code camps such as CodeStock, devLink, and IndyTechFest) that I could to learn from SharePoint MVPs.  I read many books, listened to podcasts, did hands-on-labs and watched many training webcasts.

Since I have a background in Document Management and Imaging and a huge interest in search, libraries (book kind) and improving user interactions, I really liked what I saw.  I saw SharePoint as a good platform to further my development skills as well as bring the information architecture into the fold.

I studied and passed the Moss application development exam and wrote a few connectible web parts to help out colleagues.   I did not pursue configuration exams since I did not want to be pegged an IT/Infrastructure person (since I’m not).  The more I talked to consultants doing SharePoint locally, the more it became apparent that there is little custom development at the current time (at my employer and location) and that much infrastructure knowledge is needed.  In order to excel at this type of job, I would need to work with an experienced team for some time to develop those skills.  Something a client would not be willing to pay for.

As I love software much more than hardware,  I decided that SharePoint was not where I wanted to be at this time since I would rather be learning advanced development (patterns, AOOP, TDD) and upcoming technologies (WCF, Linq, WF, WPF) with my time.

I am now working for a client on YACPPP (yet another C++ project).  I am just getting started but have been told the code base is well designed in a OOP type of way – so I am anxious to learn how it is architected, see the code  and dive back into C++ (there is much new (for me) to learn in this older technology) .  On the side I am going to learn how to be a better developer in the other areas mentioned.

So SharePoint is out of my thoughts for now, possibly in the future I’ll attack it again when I can from a development angle.  The best part about SharePoint is the community.  I am astonished at the hundreds of SharePoint bloggers working to share what they have learned and the passion I see many have around SharePoint.   All of the SP experts I have met, such as Rob Bogue, Doug Ware, and Rob Foster have been great and  I will keep my eye out on twitter to follow the SharePoint (r) evolution.

maggie++

There are many styles of interviewing software developers.  The best processes are those that allow you to see if the candidate is a good fit for your organization and for the candidate to see if your company is a good fit for them.  Shortcomings on either side can lead to costly mistakes and wasted time on both sides.

When I worked on the GSM switch project at Motorola in the late 80s we spent considerable time recruiting software engineers.  Our process was typically:

• one engineer would escort candidate from HR to the office area giving a short tour on the way.
• manager would briefly talk with them and explain the project at a high level and the day’s schedule.
• depending on candidate’s level and on our availability 2-4 engineers would individually give technical interviews.
• one interview would include lunch out in a local restaurant.
• the manager would meet with them again for any follow-up questions and to inquire which part of the system they were interested in before they were escorted back to HR.

This was in addition to the countless hours looking through resumes, phone screen beforehand and HR’s interviews with them before and after ours.

My interview technique was to first have them explain their previous projects and I asked questions where I needed clarification.  Then I would draw a high level architecture diagram of my subsystem and explain how it fit into the product and its purpose.  I would let them lead at this point; I was looking for them to show an interest and curiosity about the system by asking questions and an aptitude for talking about a system from both a high level and a detailed level.  I was looking for inquisitive thinkers who seemed eager to learn and work on a team.

 The candidates did not usually have nor did we expect them to have any telephony experience or knowledge of cellular (analog or digital) phone networks.   Most did not know C or assembler nor had heard about the object oriented concepts we were designing with.  These were important, but at the time software engineering was all about design and process and not at all about the underlying technology.  In fact we did not know ourselves at the beginning if we would be using C++ or C.  Our previous phone switches were coded with assembler.  We ended up using C as the C++ cross-compilers were not proven for our processors at the time and would have been an unnecessary risk.

This process consumed much time but we ended up with an outstanding group of software engineers.

Two podcasts I’ve listened to this past week have had content on more recent interview practices.  First was Episode 16: Interviewing Software Developers from Herding Code.   From the show notes:

This week Kevin leads a discussion on interviewing software developers:

• What interview styles we find effective
• What sort of questions actually help us evaluate a candidate
• Why API trivia and puzzle questions don’t work
• Hiring mistakes we’ve made based on errors in our interview style
• Why we don’t do very well when the tables are turned and it’s our turn to be interviewed"

Second one was a podcast featuring Scott Kriens, of Juniper Networks, from Stanford’s Entrepreneurial Thought Leader Speaker Series brought to my attention by Dianne Marsh on twitter.   While the entire talk is not about interviewing there were a few points he made about attracting talent and employee growth that are of interest to the topic.  The first (watch here) encourages developers to embrace challenging interviews and not to let them intimidate you and the second one (watch here) talks about the value of training the employees you have rather than hunting for the one star player.  He states:  “It’s better to give somebody that’s never done something before the chance to do it, then to ask somebody who’s already done it to do it again with energy and enthusiasm. ... There is a real power and passion to prove yourself.  ... They will surprise everyone with their ability to succeed.”

The first one is hard for the candidate and the second is difficult for the employer.   I know times have changed much about the way software is built and funded and a full-day interview would indeed be a luxury and quite costly for all involved.  However getting good thinkers and problem solvers on your team instead of good test-takers is key.  Paying for training and the costs from missed work time can be great but by embracing education as a means to train and retain their developers , companies will see positive results with enhanced productivity and retention.   When growth brings the need for more developers I think an approach that enables both sides to really get a good understanding of each other is prudent.

What techniques do you find useful for finding good developers and what as a developer do you do to find a good employer?  Please leave comments with your ideas or blog about it and comment here so we can learn from each other.

maggie++

My first entrance to my programming career is described in How I got started in Programming and leaving to be a full-time SAHM (stay-at-home-mom) in Taking an off-ramp and an on-ramp in IT.  This post will attempt to describe what steps I took to re-enter the workforce.

We were living in Kingsport, TN  in 2001 when I started to think about returning to work.  I felt the first thing I should learn was where the programming profession was;  I knew it had to be radically different from when I left in 1990. At the time I did not know anyone there who worked in software or anything remotely similar.

[2001 -2002] I started a subscription to Dr Dobb's Journal and searched on the internet to find anything I could to learn about software; I did not really know what I was looking for. I joined the internet forum Systers and scoured the library for technical books.  I purchased Microsoft Visual C++ .NET Deluxe Learning Edition and 4 flavors of Java in a NutShell.  I completed the tutorials in both languages.  Additional books I bought and read during this time included:

• The Pragmatic Programmer

• The Humane Interface

• The Practice of Programming

• Design Patterns Explained
  

[2003] We moved to Cincinnati, OH both to live near some family and to obtain better educations for our children.  We wanted our son to attend my husband's alma mater, St Xavier High School, and we wanted choices for my daughter for middle school.  Moving and building a house took most of my energies that first year. I continued to read and search the net and visited the library and read books such as Code Complete, The Mythical Man-Month and a variety of books on Extreme Programming.  I Joined the Cincinnati Programmer's Guild and The Women's Circuit.  I attended meetings for both groups and started to meet "real-live" people that worked in the industry and was exposed to a very wide variety of topics and ideas. 

[ 2004] By 2004 I was starting to gain confidence in my software abilities.  I started looking at job advertisements all over the internet. I determined that there seemed to be more .NET jobs than Java in Cincinnati so I started to narrow in my focus on .NET.  I discovered C# and spent a fortune on books including:

• Programming Microsoft .NET Core Services

• Programming Microsoft .NET XML Web Services

• Network Programming for Microsoft Windows

• Domain-Driven Design

• The Unified Modeling Language User Guide

• About Face

• C# Cookbook

• C# in a Nutshell

• Head First Design Patterns

I wanted to take some college or graduate classes but was disappointed to find out that you had to apply for a degree in order to take a class.  I did not want to pursue a degree at that time as I already had a math degree and had completed all of the coursework for a MSCS.  I knew my job search would be difficult considering it had been a very long time since I had been employed and I wanted to prepare myself as best I could. Taking classes was the only way I knew to "prove" on my resume that I had skills. So during the summer I took C# and Relational Databases with SQL classes at the community college.  I really learned nothing new about either C# or relational databases.  The biggest value in the classes was exposure to using Visual Studio and SQL Server software as well as being able to ask questions of the instructors.

I then paid for a week-long training class "Developing Microsoft ASP.NET Web Applications using Visual Studio .NET".  This course was great as it introduced me to ASP.NET, ADO.NET, IIS, Web Forms, Web Applications and XML Web Services and also taught me how to use more features of Visual Studio.  I also learned much from the questions the other students asked as they were all employed and transitioning from asp to ASP.NET programming.

Once the Cincinnati .NET User's Group started in the end of 2004 I began attending and was happy to see many familiar faces from the programmer's guild.

Once I updated my resume with these recent skills I began to see a sharp increase of interest and started going to interviews. The interview
 process is time of growth. I started out extremely nervous but each one got better.  Once I was able to see for myself how many different companies opperated and managed software I knew more about what to ask and what to look for.  I was able to refine my resume, read the job postings with more knowledge and was able to write detailed direct cover letters that got me in the door.  In March of 2005 I started work for a small micro-film/imaging company on a C# Tablet PC application. 

I absolutely loved being back at work. It was a long journey but very much worth the effort.

maggie++

CodeStock's mission is to bring the best and brightest code experts to East Tennessee for a one day conference open to all developers.

Are you among the best and brightest code experts?  If yes, then you are probably already registered.  If not, but you want to be, sign up and join me at CodeStock to learn and keep up with all of the new ways to improve your software skills.

There will be 6 choices of classes during each session and what I'm excited about is there will be Open Spaces all day where you can share and learn about whatever you are interested in. 

Open Space is a way to bring together groups of people interested in a common topic to have an interactive discussion. In an Open Space session, there may be an expert who is passionate about a topic presenting to an audience or there may be a small group of people discussing an idea.

Four principles of Open Space:

1. Whoever comes are the right people to be there
2. Whatever happens is the only thing that could have happened
3. Whenever it starts is the right time
4. When it's over, it's over

This is my kind of conference - a place where I can learn from other developers in a relaxed setting in beautiful Tennessee.  

Hope to meet you there.

maggie++

Michael Eaton has requested developers to share stories of how they got started in programming.  I started programming in the dark ages which many of you will not be able to relate to, so bear with me.

First of all, when I was a child no one had computers in their homes.  The only computers I knew about were at the universities and the government.  When I was in junior high, my school decided that it needed to give more focus on math and reading so it established a new format for Fridays.  Half the day was for math and half was for reading - this was set up to ensure everyone knew the basics.  Well those of us who were advanced past the basics got to hang out with the social studies teacher and learn fun things; I think there were about 10 of us.  He taught us Algebra and Geometry, we put on a play, learned about Fibonacci and many other cool things. 

Best of all he had access to a computer as he was taking graduate school classes at the nearby university.  He taught us the BASIC instruction set and had us write out programs on loose leaf.  At night he would go to the computer lab, type in each of our programs and bring us back the results.  This was the most fun I can remember from grade school.  Math was always my favorite subject and I loved puzzles and problem solving.  I don't remember too many specifics about the programs except I recall something with biorhythms and calculating things like how many days we had been alive.

My high school had a teleprinter with a tape in our math center.   I never had a chance to learn how to use it.  I envied my older sister who took an independent study class and got to (that she had a programmable TI calculator is another story).

My chance to program for real was in college.  I majored in Math and started taking computer science classes right away for a minor (at the time the college did not offer a major in CS).  We did not have our own computer, instead we had time-sharing with the mainframes at the University of Maryland. I learned assembler, Fortran, COBOL and Pascal.  Assembler and Fortran were coded with a line editor on a teleprinter; COBOL required punch cards and by the time I took Pascal we had CRT's - The summer before my senior year I had a mathematics summer internship at COMSAT Laboratory where my job was to write a program in Pascal to compute an algorithm for a mathematician.  The first day he gave me a 23 page hand written integral which was my assignment for the summer.  COMSAT was exciting - this is the first place I had ever seen real computers, plus they had a huge (satellite-sized) anechoic chamber, earth stations, library, and tons of special purpose electronics and engineering systems. 

The important things that happened that summer were I discovered that the mathematicians did not use computers at all, there was a lot of money to be made writing software and I met my future husband who was a RF Engineering Co-op.  The first didn't end up being true but the other two were good.

Once I graduated, I started job hunting.  I had success at my first job fair.  I walked around the room and talked to all the men and one asked me if I knew assembler.  I said yes I knew Univac Assembler, he smiled, gave me a business card and set up an interview for me.  I looked up and saw that the company he worked for was Sperry Univac.  I started work right away.  We were a subcontractor for Ford Aerospace on a NASA contract.  I worked on a 16 bit (hex) mini-computer with ASCII and two's complement arithmetic and communicated with a 36 bit (used octal) mainframe that used 6 bit Fieldata and one's complement arithmetic.  Needless to say I learned a ton, met great people and saw a successful large project installation.

The most fun I had at that job was testing in the lab with the mini-computer.  I loved being able to toggle switches to set a breakpoint and look at indicator lights (the only UI) to read the register contents and memory, following along with a printout of the assembler code with addresses and the op-codes.  I liked making up  and applying patches on the fly when I found a bug. A also liked getting a memory dump of the processor and searching through the buffer pool looking for buffers that hadn't been returned and ones that overwrote their boundaries.  I had full control of the machine and yes I am a geek.  I still eally like debugging - yes I know 'm a geek.

At the same job the boss felt it was important not to work through lunch so we played bridge, then when Trivial Pursuit became popular and we had more people we played that.  Some days we just hung out at the terminals and played zork.

Ok, enough with history and back to the questions.

What languages have you used since you started programming?

At least 5 assembler languages, BASIC, meta-assembler, Fortran, Pascal, Smalltalk, Prolog, Lisp, C, Cocoa, Java, C#, and C++.

If you knew then what you know now, would you have started programming?

Absolutely.

If there is one thing you learned along the way that you would tell new developers, what would it be? 

Don't stay at a job you hate with people you don't admire.  You want to be in a group where learning and communications are encouraged and required.

 

maggie++