Why This ME Became a Software Consultant

Fifteen months ago this week, I started my new occupation as a technology consultant. I spent the previous 16 months in the R&D department of a thermoelectric company as a mechanical engineer. What would cause a mechanical engineer to unexpectedly quit his job and change industries entirely? This is my story.Why This ME Became a Software Consultant

I have three degrees from Dartmouth, all with the word "engineer" on them. None of them have the word “software” or “computer”. Nonetheless, every job offer I received after college involved writing code except the one I accepted. I wanted to give mechanical engineering its chance, to see if the industry could reproduce the culture I had found and loved during my time in school. Here is what I discovered and why I changed occupations to software consulting.

1) Timeline: I'm impatient. We take the Predictive Index at my current employer and my overwhelming trait is low patience. Mechanical engineering works differently. The timelines are in years or decades. Prototypes could take weeks or months to arrive meaning the iterative process is at least that slow. Contrast: I'd go home at night and turn out a brand new feature on an app I was writing in a matter of hours. I could see results instantly. It was gratifying and addictive.

2) People: In engineering, I worked with mostly people in their 40s or 50s. No one was in a rush to get promoted and most were happy just to have a job. There were no misconceptions that we were doing anything cool that would change the world. We were mostly there just to design some new stuff and hope somebody bought it. Contrast: all my co-workers are my age. Our managers are in their 30s. Our Principals and VPs are in their 40s and 50s. This means I actually enjoy hanging out with my co-workers. We're similarly minded and career-driven. Our management arrived at their position because they were too, making them great resources. Additionally, we get to build some really cool stuff and, as a result, we're excited about what we do.

3) Corporate Structure: I had been working at my engineering company for 16 months. My direct manager had been there for 10 years. His manager had been there for 35 years.  Needless to say, I wasn't going anywhere fast. The path before me was to take cost of living increases for years until someone retired and then we all moved up. Contrast: I'm up for promotion every 12 months. My promotions are based on my performance, not the actions of someone else. My earning potential and the demand for my skills are both much greater.

You combine these three things and you get drastically different cultures. I still love mechanical engineering, but more in the pure sense rather than the industry implementation. If you're thinking about what to major in, choosing your first job, or contemplating a career change, think through these three things and what culture best fits you. For me, I’ve found software consulting to be a perfect blend of consistency and new challenges, security and new opportunities. I get to work with great people solving hard problems for interesting clients and it’s hard to ask more from a job than that.

About the Author: 

Scott Decker fell in love with writing code in college. He had a brief foray as a mechanical engineer before taking a job at Pariveda Solutions in Dallas, TX in 2013. He blogs here, tweets here, and is emailed here. You can also find him on LinkedIn. If he’s not writing code, he’s probably exploring the closest mountain range with his wife and dog.

Posted in: 
Job Seeker

You Won't Find These Things On Our LinkedIn Profiles

LinkedIn recently posted this blog where they filmed recruiters talking about jobs, experiences and skills that are not on their LinkedIn profiles. I enjoyed it so much that I decided to make a special MATRIX edition.

This is just a small snippet of what makes up our team here at MATRIX. Thanks to everyone who shared the best (or rather, most entertaining) parts of your past!

Your turn: Post in the comments below or tweet at @MATRIXResources the things that aren't on your LinkedIn profile.

About the Author: 

Jennifer is the Community Manager for MATRIX. She manages all social media accounts and community partnerships in our different markets while assisting the marketing department. She loves pop culture, Oklahoma football and the great state of Texas. Feel free to connect with her on LinkedIn.

Posted in: 
Fun

Tech + Social + Collaboration = FAIL.

As a Developer, when I have an issue I’m trying to solve, I turn to Google. Most of my fellow developers do the same thing. Sites like Stack Overflow and MSDN are usually at the top of those searches. This is because the questions are public and the answers can be given either by the community at large or, in the case of MSDN, by Microsoft themselves.Solaborate

When I’m ready to start learning about the next big thing, I turn to Twitter and my long list of follows is always ready with tweets about what I need to care about.

Do we need a unified site that brings both of these concepts together? I’m not so sure. One newcomer to the Social/Collaboration scene believes they have done it.

"Solaborate is a social and collaboration platform dedicated to technology professionals and companies to connect, collaborate, discover opportunities, and create an ecosystem around products and services. Solaborate provides technology professionals a central place with the right tools and services to collaborate in real time. It's a new way for the tech community to be more productive.”

The new social network tries to merge a techie’s need for collaboration and answers with his/her need for knowledge sharing. Unfortunately, it’s centered on LinkedIn-like or Twitter-like connections. This means you’re only going to see information shared by people you connect with. Furthermore, only people you’re connected with will see your posts, even when marked “public.” This potentially solves the Information Sharing or “Social” aspect they’re trying to accomplish. They even offer video/audio calls and text chatting.

However, the same concept of connection-based communications hobbles their ability to be a collaboration center. If I can only ask my connections and can only see questions asked by my connections, how can I be sure I’m following community best practices? I need to be able to ask the entire community. Because of this, I would not be inclined to use Solaborate for collaborations on issues I’m facing; Google will still be my go-to place to solve problems.

If I’m not going to use the “collaboration” aspect of Solaborate, and am only left with the social features, I don’t need it. I already have all of those features on LinkedIn (and Facebook, Twitter, etc.) I think Solaborate has a long uphill battle if it wants to gain momentum in the market.

About the Author: 

Todd Azbill has been a software developer since 2000. His comfort zone is the Microsoft Stack, but he's flexible. In recent years, Todd has become an Agile Enthusiast and he finds himself gravitating towards the realm of Agile Leadership.

Posted in: 
Fun

Blog Response: Internships ARE Worth It

“Internships aren’t worth it.” When I saw this article from Forbes last week, I was surprised, and a little indignant. I grew up being told that the only way to get a job after graduation was by stacking my resume with internships throughout college. And honestly, I don’t think I would be where I am today if I didn’t have those internships.

The summer before I graduated from the University of Oklahoma, I landed a Social Media/Marketing internship at MATRIX in Dallas. The reason I got this internship was a combination of my interview and the experience I had on my resume. My boss would not have hired someone with zero experience to jump into this job that was essentially the voice of the brand.  The Internship

Granted, Henderson is generally talking about unpaid internships in her article. I was fortunate to have a paid internship with MATRIX. But believe me, it was nothing like the Google movie or the rest of these internships that pay more than the U.S. median household income. Even though I wasn’t in a high-paying tech intern program, I would repeat my internship in a heartbeat, paid or unpaid.

To Henderson’s first point: “The work doesn’t help you build useful skills”, it’s impossible to generalize here. Sure, there are internships that don’t build real skills, but I would like to think that these are not the majority. Even though I was just a college student, I was not the lowly coffee girl at MATRIX. I was tasked with building and managing social media accounts from the ground up and driving engagement. I had direction, but ultimately, I was given the reigns on really owning our online brand. My colleague, Jessi Byas, took an unpaid summer internship as a PR/Social Media rep on a political campaign in 2010. She was thrown right into the role and given responsibilities such as writing press releases, managing fundraising events, running social media accounts and more. Even though she wasn’t paid, she honed skills in this role that led her to where she is today. “As a PR major, I was able to use what I learned in my classes in a professional setting. I got a firsthand look of the inside of a campaign and even as an intern, I got to work alongside the candidate as a real member of the team,” said Jessi. There are plenty of companies out there that will treat their interns with this kind of respect.

When you get out of college, it’s almost impossible to get a job in an office without some kind of relevant experience. The most likely type of experience prior to entry-level positions? Internships. When interviewing at a company, the interviewer will look at your experience and ask what you did at your previous jobs. They don’t care if it was paid or not; they care about the skills you picked up.

Are internships worth it? I can’t speak for everyone. What Henderson doesn’t mention is how any kind of intern experience will teach you something about yourself. Maybe it doesn’t pay anything, but it shows you what it’s like to work in the business world and teaches you office etiquette before you start your real job. Maybe it trains you on taking orders well and meeting deadlines. (Actual, real-world deadlines, not like the paper you had to turn in to your English class last semester.) Or maybe it teaches you that you actually hate corporate environments and leads you to explore a different line of work. These lessons can be worth so much more than money. Maybe you’ll get lucky like me and your internship will turn into a full-time job. Are all internships going to be right for you? No, probably not. But don’t let lack of pay or articles like this keep you from getting real-world experience that can be the stepping stone to your dream job.

So what do you think: are internships worth it? Does the pay matter to you? Share your internship experiences in the comments.

About the Author: 

Jennifer is the Community Manager for MATRIX. She manages all social media accounts and community partnerships in our different markets while assisting the marketing department. She loves pop culture, Oklahoma football and the great state of Texas. Feel free to connect with her on LinkedIn.

Posted in: 
Job Seeker

A History of Failure: Learning From My Failed Products

Right now you’re reading the blog of someone who has had no major success building a profitable SaaS solution. Writing customized software for clients as a consultant? I have that down (though always looking to grow). But building a profitable SaaS product: not yet. So why should you take my advice about building one? I have a really great track record of failures that I hope can help you when you’re building your next product.Learning from Failure

Building a failure of a product is no fun, but each one serves as a great learning experience. Each one of my failures have influenced the next product I built. I’m building my three new products differently now that I have several failures under my belt.

Lastly, I don’t want to promote the idea that having a failed product is necessary to be a competent entrepreneur. Unquestionably, I’m envious of people who have successful products on their first try. However, I’m always suspicious of those success stories; sometimes a success story is better sold when the list of previous failures is left to lie silent.

Kwolla
The first product I sold online was named Kwolla. Kwolla was the result of a failed startup I was hired to build. Kwolla was originally named Prospect Vista and was a social network for businesses. You could think of it as a merge between YouTube and LinkedIn because a public profile that advertised your business was the value proposition. There are many reasons why Prospect Vista failed, but we decided that the software behind it was still valid, so we packaged it up as a social-network-in-a-box tool. For $79 you could buy a copy of the software, install it on your server, and instantly have your own social network.

Selling Kwolla actually went very well. In total, I sold $2400 worth of software and Kwolla consulting combined.

Kwolla failed because I essentially shut it down. I made two big mistakes. First, I had this notion that I no longer wanted to write PHP anymore, and thus was going to rewrite Kwolla in Scala. Second, I actually started rewriting Kwolla (in PHP albeit)! This was insane. In my hands, I had a product that was making money and I shut it down because I didn’t like the codebase behind it. The code was sloppy in places and it bothered me. So I completely killed it.

It was a horrible decision. I wish I would have kept on building the Kwolla site and product. Over time, I could have refactored the code and made it better. But, the engineer side of my brain kicked in and I couldn’t deal with the bad code.

Key Takeaway: Don’t rewrite major software applications from scratch, and keep on with a good thing.

Accthub Version 1
After I shut down Kwolla, I went to work for an e-commerce company for a while. I concentrated on building my consulting business on the side in that time, and didn’t really work on any projects for myself. While at the company, I had an idea to build a centralized user management API so that our many different e-commerce sites could communicate with this central user management API. I was itching to build a product again, so building this central user API seemed natural.

I wrote out a spec and eventually built the API: Accthub. A hub for all of your accounts. Neil, my co-founder at Bright March, designed a beautiful landing page and we built a great marketing site around Accthub.

We launched to absolutely zero users. We attempted to market it as a Parse for user accounts (even though Parse had user accounts). In total, 76 people signed up for the service and not a single person paid for it.

Ironically, even though this idea failed for us, two other companies are building it: Stormpath and UserApp. It’s clearly something people wanted, I just hope they have more success than we did building their applications.

Key Takeaway: Do market research before you spend a tremendous amount of time and effort building a product. Launching it to no one doesn’t help at all. Even worse, I originally wrote Accthub in Java and then completely scratched it and rewrote it in PHP because I knew it better and was more comfortable with it.

Accthub Version 2
It’s funny how the key takeaway in the first iteration of Accthub didn’t hit us until after we attempted to re-build Accthub again. The second version of Accthub aimed to be like Mozilla Persona, except not free, not from a major highly respected non-profit company. Essentially, you, the Internet user, would register an account on Accthub and then use it to sign up for other sites that integrated with Accthub. Then, you could give explicit permissions as to what every site could do with your data that you let them use.

This idea sounds really cool, but there are a lot of problems with it. Who is going to pay for it? Internet users won’t, they’ll clearly give their private information away for free without any thought. Companies won’t pay for it, they can just use Facebook, Twitter, or LinkedIn authentication.

We applied to Y-Combinator with this idea and didn’t even get an interview.

Key Takeaway: Really validate your idea before you build it. With Accthub Version 1 we got some traction. Fortunately, with this version, getting rejected from Y-Combinator was enough for us to scrap it before we built it in earnest.

MajorApi
MajorApi was the first product we built that showed a lot of promise. With the strain of failures behind us, we knew we wanted to approach MajorApi differently.

MajorApi was born from the idea that integrating with QuickBooks is really, really difficult. Way more difficult than integrating with any database (essentially what QuickBooks is) should be. We were working on integrating with QuickBooks for a client and spent a huge amount of time just figuring out how to connect to QuickBooks and send in and extract data. Judging by the the thousands of StackOverflow and random forum posts out there, we surmised a lot of other developers were having this issue as well.

So we came up with an idea: a REST API for QuickBooks. We finally cracked the “integrating with QuickBooks” code, and felt that if there was a service that charged a monthly fee to provide a nice API on top of the horror that is integrating with QuickBooks that developers would come rushing in to use it.

To validate this idea, we set up a simple landing page. It explained the problem, our idea, and our proposed solution. I submitted a link to it to Hacker News on a Saturday night in early December 2012. That night, the post blew up. We had several hundred people sign up for the mailing list saying they were interested in what we were building.

Even more encouraging, Intuit themselves caught wind of the landing page and flew me out to Mountain View to spend a day with them. They offered me a very nice job in exchange for not building MajorApi. Stripe was also interested in integrating MajorApi with their service. So, when Intuit offers you a job to not build something, and Stripe wants to integrate your product with theirs, and you have hundreds of people interested in using it, it’s definitely time to build your product.

I declined the job at Intuit and built MajorApi. And three months later in March of 2013, we launched it. And people started using it – kind of. And then really not at all when you really looked at the analytics. Mailing list people signed up, saw they had to download a piece of software, and it only worked for QuickBooks Desktop and that was it: they were gone.

We also applied to Y-Combinator with this idea which we felt surely would get us an interview only to wind up completely rejected again.

MajorApi limped on for the last year. We finally shut it down in January 2014 and are in the process of open sourcing it.

Key Takeaway: We built a product that people were interested in, but we built it in a silo. We didn’t reach out to any members on the mailing list while we were building it to find out what they really wanted or were willing to pay for. Instead, we kept our heads down and built a product we thought people would have wanted. I would have much preferred to launch to 20 developers immediately ready to start paying $50 a month for this service than 200 people who created a free account.

Final Thoughts
Building a successful product is hard. Very hard. I’m not ashamed at all about my failures. Even the most successful products out there were most likely built by people with a long history of small failures that they learned and grew from.

It’s always best to put another tally mark in the Successful column, but don’t be ashamed of the ones in the Failed column either.

About the Author: 

Vic Cherubini started writing software professionally in 1999. In 2011, he started his own software consulting company Bright March. He loves writing about software engineering, entrepreneurship, and personal growth. To read more of Vic's posts, or get in touch with him, visit his website.

Posted in: 
Development