Maggie++

“Ada Lovelace Day is an international day of blogging to draw attention to women excelling in technology. Women's contributions often go unacknowledged, their innovations seldom mentioned, their faces rarely recognized. We want you to tell the world about these unsung heroines. Whatever she does, whether she is a sysadmin or a tech entrepreneur, a programmer or a designer, developing software or hardware, a tech journalist or a tech consultant, we want to celebrate her achievements. “

Suw Charman-Anderson, a freelance social software consultant in the UK established this day by pledging to blog about  women in technology if at least 1000 people joined her..

“I will publish a blog post on Tuesday 24th March about a woman in technology whom I admire but only if 1,000 other people will do the same.”

She points out that research shows that women need female role models and wants us to take part by acknowledging women in technology in our lives.

As a female Software Engineer I have had many women inspire me throughout my career including:

• Colleen Berg
• Anita Borg, founder of Systers
• Carolyn K., founder of Hoagies Gifted
• Suzanne LaChapelle, founder of The Women’s Circuit
• Dianne Marsh
• Jennifer Marsman

I wish to thank them for their inspiration to me and others.

You can follow FindingAda on Twitter and use #ALD09 to find more information today.

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.

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"

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++