AlI I really need to know about software I learned at my dotcom startup

Many moons ago I worked for a dotcom startup. I am sure there are some of you out there that remember those heady days. While in retrospect we probably shouldn’t have spent all that money on funky office space and astronomical salaries, we had a blast. We worked hard. We played hard. It was a glorious 3 years of my life that came to an abrupt halt when the dotcom bubble burst. Poof. Done. Over. Move along. Fortunately for me, I had some good connections, and was able to dust myself off, and land on my feet. After a stint at a large multinational, I am now at Constant Contact.  Constant Contact in my mind is the best of both worlds. It has all the great small company energy and friendliness combined with the stability of a publicly traded firm. Like my beloved startup it is a fun, innovative, and engaging environment where I get to work with open-minded and collaborative individuals, yet I have a matching 401k, yay! And it is also a place where I am happy to see many of the principles I learned in my dotcom days in effect or taking shape. While the technology landscape has changed dramatically in the past 10 years, there are some essential aspects of software development culture, process, and practice that remain as true now as then. Here they are:

Code quality comes from a shared sense of ownership

At my startup, we had check-in log that we had to fill out whenever we did a code check-in. This was not a trivial 1 line comment about the change, this was expected to be a very detailed account of what you did and why you did it. This way anyone reviewing your code or the check-in log would understand what you were doing and why you were doing it. What made this so effective was that EVERYONE read the check-in log. If you forgot to write an entry or it wasn’t detailed enough you got called out on it. This might seem like a bunch of busy bodies in everyone’s check-in business, but it never came across that way because people didn’t do it to be a busy body, they did it because they cared about the code and what you were doing in it. This is not true everywhere. At the large multinational company I worked for after my startup, it was almost impossible to get people to look beyond their little piece of functionality.  The code was horrible, fingers were pointed, and no one did anything to improve the code.

At Constant Contact we use GitHub. I love GitHub for coming up with the pull request paradigm. We use it extensively and it is great to see people chiming in about someone’s code. Developers refactor based on peer’s comments, fix potential issues that their coworkers point out, and collect ideas for future improvements.

Just drink the Kool-Aid

This was a favorite saying of our startup CTO with respect to coding standards. For example, we had a coding style guide and regardless of how you felt about the style guide (people would politely listen to your arguments for or against a way of doing something), but at the end of the day you were expected to “just drink the Kool-Aid”.

At Constant Contact, our VP of Eng. uses the term “Shared Vision”.  It doesn’t mean consensus, but rather than spending time arguing, accept the decision, and make the goal happen. “You can disagree while making a decision, but once it is made everyone needs to be behind it 100%.” Those are the marching orders. Drink the Kool-Aid and get to work.

Open office space enhances collaboration

Our startup CTO was ahead of his time and had a desk right out in the bullpen with all of us. This enabled him to keep a finger on the pulse of the team, chime in when necessary, swoop in to make a command decision to help push things through and contributed to an open, transparent and collaborative environment.

At Constant Contact both our NYC and San Francisco offices have been set up this way, and our Waltham office is transitioning over. Check out some of our office space pics. 


Our San Francisco office


Life in Waltham

Although I am a highly paid programmer, I may need to do the dishes

When you are at a small company you need to step in and wear many hats because you don’t have a lot of staff. Watching everyone help keep things neat (or occasionally the person who didn’t help keep things neat) gave me an insight into servant leadership. Sometimes in order to make things flow smoothly you may be need to do something outside of your job description. Don’t wait to be told to do it, just roll up your sleeves and do it – that is okay. Nothing is beneath you no matter what your job title. It is a contribution and all contributions matter.

At Constant Contact we might not have so many dishes to do, but there are many examples of this “roll up your sleeves” ethic. On the cross product team, which is designed to be reactive and flexible to market input, there are times that the QE team can get overloaded.  It is common on the team to call a “QE” day, where all development stops and developers take on any quality task, whether that is running manual regression tests or writing and automating tests on the QE backlog. We are all in this together, so ask yourself “what can I do to help?”


Unit testing

Okay, there has to be exceptions to every rule, so this is the one thing I did not learn at my startup. This is actually something I learned from my large multinational because, of course, they did everything the wrong way. There were little to no unit tests, and with a huge and cumbersome codebase. We paid dearly for this lack in automated testing infrastructure by being paralyzed when it came to making changes to legacy functionality. The risks were too great that we would break something. I now firmly believe that unit testing is the only way to guarantee that as the code and complexity grows that you have a way to detect regressions.

At Constant Contact we not only require engineers to write unit tests for the code they develop, we have the most astute group of Quality Engineers who put the Engineer back in QE. They write almost as much code as my engineers write to automate as much of the testing as they possibly can.


Everyone loves having a shout out now and then. At my startup, we had a mailing list that you sent an email to when you were feeling particularly positive about something. I love the idea of letting people know the little things they have done that have made your life or job easier. We all need a pat on the back and this was, and is, a great and cheap way for people to feel the love.

At Constant Contact we have a variety of ways to 


give recognition. The WOW award works along the same lines as the “positive”. You just send a quick email to the HR team, and a funky little WOW guy shows up on the person’s desk, and they are recognized at company meetings. We also have awards for innovation projects (handed out every quarter at the end of our Innovation Jams) and for excellence in product delivery. So while Constant Contact’s system is more elaborate, it still keeps things positive and that is just so positive!

Yearly reviews are going to be a positive experience, because if it isn’t, then we have a problem

This is what my startup HR person (who was also the controller and the office manager) told me when I first started. Employees need frequent and honest feedback. If you can’t have a positive review, then you need to address why you can’t have a positive yearly review. Getting feedback on your job performance only once or twice a year stinks, and it really stinks if that precious interaction is full of negative feedback that you didn’t have a chance to address and from a time you can barely remember.  The yearly review should be a super positive love fest (because if we don’t love you we would have gotten rid of you by now).  The other thing that my startup did, that I still do now, is put direct positive quotes from peers in the review. While we all would like for people send emails to the positive email list, there is a lot of appreciation that goes unsaid until review time. This is a great chance to pump up the team and get people super motivated. Again if you have someone that is not an “A“ player, they should be actively working towards being an “A” player. The review is a perfect time to talk about progress towards goals while still being a positive conversation. Save those hard conversations for a time when the pressure is not so great – a nice Tuesday afternoon in May is fine. But save the big review for something special. Think of it as Valentine’s Day for your employees. I heart you.

Interested in working at Constant Contact? Visit to learn about open positions.


  1. David Bortone says:

    Great article Amanda! I’m sharing it with the Engineering team here at my current company.

Leave a Comment