Category: Software Development

19 February, 2013

How to be A Team-player in an Agile Team, Part 1

by Frances Advincula

The last few days was my first foray into the agile practice of the planning game, wherein stakeholders, programmers, and the rest of the team go in a room and brainstorm, think, talk, and fight in order to come up with what we are actually going to build. It was really mind opening to just see how the dynamics work — the software architects and programmers tend to really have lots to say, because, well they’re the ones going to build the software. On the other hand, it was also interesting to see how the QA and the documentation team asked a lot of questions, and usually ones that customers will most likely be asking. It really reinforced me once again how great debate and teamwork ultimately leads to a better product.

Seeing the value of a synergistic team, I thought I would expound on my previous article on how to work more effectively with your team by interviewing a technical writer and a scrum master (who we will keep anonymous for this post). Our technical writer Bonnie Doyle Chase has worked various documentation and product management positions. Follow her grammatically correct tweets at @bonniedchase.)

On the Value of Documentation

Let’s start with appreciating the work of the technical writer on your team. I think it would help us, as developers, to know where they are coming from, so that we can work more productively with them.

I know sometimes developers tend to brush off doc as “just doc”. What do you have to say about that?

We hear the myth time and again, “no one cares about documentation.” I brush these comments off because as I see it, no one knows they care about documentation. I believe this stigma comes from the amount of bad documentation people have been exposed to in the past. They didn’t have good technical communicators writing quality documentation. And there are still writers out there perpetuating this myth through bad documentation. However, there is a new generation of technical communicators out there who I like to call Docvocates. They are the ones who are actively working on eliminating this myth by producing quality work and speaking out about what we really do. I hope we can change the way people view doc, but it may take a while. These are what I view as the top three benefits of good documentation:

Eases cognitive friction
Improves the chances of product success
Reduces the number of support tickets

The proof is in the metrics. The thousands of visits we get to our documentation site, the emails we receive from customers asking for more information on a product or process, and the research completed in the field all point to the value of documentation. A lesson I’ve learned in my field (which could apply to many others) is this: Know your value, even when others do not. People read documentation; they just don’t like to admit it.

Is there anything you wish developers knew about documentation?

Technical writers don’t want to be developers. I make this statement because if you look at the history of technical communication, the initial writers were developers and engineers. It wasn’t something that people went to school for, and it wasn’t necessarily something many developers and engineers wanted to do. Sure, that is still the case in some companies that are behind the times, but for the most part, technical communication is recognized as its own profession and academic program. The field has made tremendous strides over the last decade and will continue to do so in the coming years. And it’s not just about writing. For a lot of technical communicators, writing is only 10% of what they do. They are information architects, document and web designers, content strategists, and usability specialists. Technical writers need developers for their subject-matter expertise, and developers need technical writers to bridge the gap with their users. While they don’t want to be developers, there is a relationship there that will always remain and should be fostered.

If developers could do just one thing to improve the process/help you perform your job better, what would it be?

Give technical writers time. Whether they need more information about issues to write release notes, or information about functionality to write the doc, take some time to answer questions. Doc teams obtain the technical information from developers and turn it into something understandable for the user. The longer developers take to respond, the shorter the time writers have to do their jobs. That timeline impacts the quality of the work, and it impacts how users view the product.

In your opinion, do you think doc has a place in startups?

Yes. Sam Carpenter will do a much better job of telling you why: Why Startups Need Documentation.

On the Value of Project Management

I also just started my masters at Johns Hopkins, and I’m taking a class in project management. Let me tell you — I have never appreciated my managers more! Between responding to request for proposals, creating work breakdown structures, really, my head just spun! With that in mind, let’s see how we can cooperate better with our managers (I noticed we developers sometimes can be quite anti-management.), which will ultimately help make the team more successful.

Is there anything you wish developers knew about your job?

I do wish that developers understood the importance of project tasks that don’t include coding. Most developers are good with this, but some don’t understand the importance of things other than coding. I know things like time tracking are not that exciting, but accurate time tracking is extremely important as far a project reporting goes. Which eventually rolls all the way up to asking for more funding next year to increase the team size (or to keep it the same) so that we can continue to deliver great code. It’s not enough to deliver great code. It must be on time and on budget as well.

If developers could do just one thing to improve the process/help you perform your job better, what would it be?

Communication, some developers get offended when you ask them what they are working on or when they will be done. Estimates are hard to give, and I understand that, but we also have to give them. We can handle it when we are wrong with things such as change control but often developers hate to be tied to do a time estimate.

Is there anything you wish they would stop doing?

For the most part I have always worked with great developers. One thing that is hard for them to do is to deliver code that is good enough. We should always strive for great code, but you can spend too much time tweaking code. With us trying to hit market demand we must be agile and fast. In no way should we ship bad code. Sometimes though we need to ship good code… not excellent code. This is a very hard line to decide what is good enough. It’s very hard to tell developers that as well.

Also, I know that QA and documentation are not developers’ favorite thing to do, but they are necessary evils and it makes my job easier when developers just do what they need to do instead of belly ache about it.

I hope you have learned something from these interviews as I have. I know I am very guilty about some of these sins! I especially hate giving estimates, but like the interviews said, we must all do our part to ensure that the team succeeds as a whole.

One more thing, although I am very disappointed that Femgineer wasn’t mentioned, here is a goodie-bag for your women-in-tech resources fix. Happy weekend, Everyone!

Frances Advincula writes the series Frances Fridays. Frances recently graduated with a degree in Computer Science with specialization in Software Engineering. She now works as a Software Developer for Accenture (Software). A proud geek girl, she’s sure she is the only one who can’t play video games. Follow her random musings at @FranAdvincula.

Tweet This Post

5 February, 2013

I Don’t Want to be a Programmer

by Frances Advincula

I am terribly lucky to have a lot of mentors, especially on the team that I am in. They are literally taking the adage “It takes a village to raise a child” to heart. Sadly for us, one of my mentors is leaving the team today in pursuit of other adventures in engineering land. The way the team started to mourn his decision really struck a chord in me. What made him so loved?

I realized that he was not just a programmer — he was a software developer. And I want to grow up to be just like him.

(See how sweet he is?)

According to Erick Sink, here is the difference between the two.

…a “programmer” is someone who does nothing but code new features and [if you're lucky] fix bugs. They don’t write specs. They don’t write automated test cases. They don’t help keep the automated build system up to date. They don’t help customers work out tough problems. They don’t help write documentation. They don’t help with testing. They don’t even read code. All they do is write new code. In a small ISV, you don’t want any of these people in your company.

Instead of “programmers” (people that specialize in writing code), what you need are “developers” (people who will contribute in multiple ways to make the product successful).

Thus, as part of my goals for 2013, and inspired by my many mentors, I want to be more helpful to my team throughout the entire process, always keeping in mind that great products provide seamless experiences from end-to-end. That includes everything and involves a lot of people! Here are a few reminders I wrote up for myself.

For UX

1. Suggest things that you think will improve the user experience, but realize that the UX team is the expert in the subject. They breathe this stuff. Their work goes above and beyond colors and graphics; they put real research into their work to make sure the needs of customers get met in the best way possible.

2. Work closely with them if you are in the front end, and make sure to do so from the beginning. That way, there is less re-work, unlike if you start coding already and visions end up not aligning. Also, because they may be fully aware of what is technically possible or not, make sure you understand the goals behind their design. That way, if you are not agreeing with something, you can suggest something similar that satisfies that goal.

For Documentation

1. Realize that the doc team may not necessarily speak the same techie mumbo jumbo as you. Make sure that you write good notes for your task in your project management tool. Remember that as the doc team writes release notes for customers, they are usually concerned about tangible changes that should affect what the customer sees. Write your notes accordingly.

2. Although it deserves another post on its own, never ever make them feel like they are “just doc.” Great documentation is one of those things that go unnoticed when it is really good, but are blatantly annoying when they are bad.

For Managers (Scrum Master, Project Manager, Product Owner, etc.)

1. Know their style. Some love to be emailed (so they can avoid meetings), and some love meetings (so they don’t drown in a sea of emails). Work with it.

2. Remember that managers always push for more — that is their job. Therefore, if you cannot do something, speak up. They would rather you say “no” than just keep saying “yes” and not deliver.

3. Stop whining about meetings; instead, make sure you really need to be there and take responsibility for making it productive.

For Software Architects/Other Developers

1. Write more functional specs and touch base often. That way, more senior engineers can tell you that you are going down the wrong rabbit hole before you write a lot of code.

2. If you are touching their code, especially as a newbie, let them know/ask for a code review before you commit. Of course they will see it in the commit logs, but I like to do this out of respect and to make sure the best code possible is committed.

3. Be obsessed about your code and take pride in it. Think about all the ways users can and will interact with it. Brainstorm. Really think about what you are building. Write unit tests, because they force you to really think about the requirements and what goes in — and it’s virtually impossible to unit test bad code, BUT do not rely on them as a silver bullet. Just because the unit test passed doesn’t mean the code is great. (Thank you to my other awesome mentor, Mr. J, for your great advice. I still don’t know how you put up with me!)

4. Don’t forget to spend time coding what you love, no matter how little time it is. A wise man told me that this is the difference between awesome developers and regular developers, for it will keep your passion roaring!

For QA

1. Depending on your organization and team, realize that some QA are super techie and some aren’t. Make sure that you communicate on their terms. Be sure you are clear about what your code changes will affect, in case they need to test more things than what is currently your task/unit of work.

2. Be patient with all their nitty-gritty questions. Those questions force you to think about what your code does in new ways, and will more closely mimic questions that your customers will potentially ask.

For Release Management/Dev Ops

1. Find out what they need to know from you when you commit. For instance, on some branches in SVN, if I commit, the RM needs to know if I added or deleted files; otherwise, the installs break.

2. If your commit breaks the build, fix it as soon as possible. If you like to commit a lot at the end of the day, wait for a successful build before you go home.

In a nutshell, good software developers don’t just write code. We work hand-in-hand with a lot of people to ensure that the code we write turns into a great product that makes people happy, real happy.

Tweet This Post

17 January, 2013

Cost of a Customer

Too often founders and CEOs fixate on CAC (customer acquisition cost) or LTV (lifetime value of a customer), but they fail to consider the cost of a customer. Many people tie this into COGs (cost of goods sold), but I actually think it needs to be a separate line item. To me COGs is just how much it takes to build the product, and often times for technology products and services that is amortized as an R&D investment. Hence, the cost of maintaining the product or service needs to be factored in. We need to shift our thinking because we we’re no longer making shrink-wrapped software! We’re doing SaaS (software as a service).

Unfortunately, CAC and LTV being at the forefront is a phenomenon that especially plagues startups and companies that service a broad base of customers rather than a niche market. However, the reality is that the cost of the customer can actually narrow margins significantly impacting profitability. Hence, the key is to think about what the cost of a customer is, and how it can be reduced.

Cost of a Customer

Calculating the cost of a customer is tricky. You have to begin by seeing what is driving up costs, here are three major factors that contribute to it:

The type of customer you are attracting.
Putting a price on servicing their needs.
The quality of your product or service.

The Right Type of Customer

I actually never blame a customer for asking for too much or driving up costs. The type of customer a company attracts is well within their control. It is up to the company to determine who is and isn’t the right fit for the product. In the event that there isn’t a fit the customer and company shouldn’t bother to do business, it will only cause friction and drive up costs. This is a hard idea for most founders and CEOs to adopt because it causes them to assume that it will limit their company’s growth rate.

To attract the right customer, you of course have to do customer development; understanding their needs, expectations, and what value they are seeking from your product or service. However, if you do customer development correctly, you can then craft a marketing message that is clear and attracts that particular type of customer in mass.

For example, BizeeBee offers a self-service CRM product to independent fitness professionals and businesses (e.g. yoga studios and personal trainers). We don’t service businesses with multiple locations or franchises. In making the product self-service, I knew that the type of fitness professionals we’d be able to service needed to be comfortable enough with technology to get up and running by themselves, or with as minimal customer support from our end. However, despite their degree of tech savviness, because we are focused on making a self-service product, we knew that the product needs to be as simple to use as possible. If a potential customer comes to us asking for a lot of help to get setup we tell them that we’re probably not going to be a good fit. Yes it kills the sale, but it also kills the long term cost.

At BizeeBee, we still talk about having great customer service, but because our product being self-service, lets customers know that they can get setup on their own. They don’t need to wait on us to get started. This might seem pretty obvious to most, but for our customer segment it is important to be clear with the messaging because our competitors products’ are very setup intensive. Our goal is to empower our customers and keep our support costs down.

By baking in customer needs into the design of our product, and conveying for whom and how our product addresses those needs in our messaging we have attracted the right type of customer.

Pricing Your Product

Pricing your product also helps a lot. At BizeeBee, we don’t appeal to the overly price sensitive customer. Instead we’ve concluded that the price point we offer attracts customers that value our product and our time.

If it were a free product or very low cost solution there would be an element of entitlement. The other element to pricing that people often overlook is charging the users of their product directly. Indirect approaches such as affiliate marketing and lead generation or having two users but one customer (e.g. marketplaces or B2B2C), can skew costs.

I’ve actually experienced this at my last startup Mint, because it was a free product it attracted millions of users! This is something people think they want… In reality it drove up customer entitlement (requesting more features), creating the need for support staff to handle customer requests, and put a burden on engineers to spend time building features that weren’t always revenue generating. The amount of money we were making on lead generation per customer, i.e the LTV, was significantly less than the cost of a customer.

Quality of Product

Quality is the #1 driver of customer cost. It manifests itself in the following manner:

int increases the number of customer support staff you need to address customer concerns
it increases customer churn and reduces closing rates for sales staff
it impedes the time engineers spend on creating new products because they are more focused on fixing bugs

Now some companies take the strategy of charging their customers for technical support. I think paying for technical support only makes sense if a customer wants additional maintenance, i.e to add features to a product or receive help/training getting setup. Barring those two, having a customer pay for a defective product will definitely leave them thinking twice about doing business with you going forward.

Finally, the cost of a customer will change as the number of customers go up. This is because servicing more customers means you’ll have more operational expenses such as building or maintaining infrastructure to support the larger number of customers. You can offset the increased costs by looking for services that will support the larger load. But you’ll still have an interim period of growing pains that will need to be addressed.

There isn’t an exact formula to determine the cost of a customer, but the point is to be aware of what contributes to it, and factor it into various aspects of your business namely: product quality and the type of customer you’re attracting through your marketing and pricing.

Tweet This Post

4 January, 2013

Learning JavaScript: Resources for Future JS Ninjas

If it is possible to make yourself into a great hacker, the way to do it may be to make the following deal with yourself: you never have to work on boring projects (unless your family will starve otherwise), and in return, you’ll never allow yourself to do a half-assed job. - Paul Graham

Inspired by the quote above, this year, I chose to focus on my front-end development skills because that is the work I find myself enjoying the most. In a sort of masochistic way, I even enjoy the tug-of-war that sometimes happens between the UX group and the engineering group. I just love the idea of helping solve people’s problems in the most obvious, direct — and beautiful — way possible!

Let’s start with JavaScript this week, shall we? I made the following roundup as a sort of to-do list for myself, but I hope you find them useful as well. If you have more to share, feel free to comment, and I’ll add it to the list. Happy Friday, and happy coding!

Videos and Talks

Sometimes, the last thing you want to do after a long day of coding is code some more. Fear not! Adyy Osmani has got us covered.

Talks To Help You Become A Better Front-End Engineer In 2013. The massive collection has a lot on JavaScript including the future of the language, design patterns, architecture, localization, etc.

Need some more? 8 Hours Of The Top 10 JavaScript Talks From 2010 That You Can’t Miss

Books

If you’ve been reading my posts, you know I like to list books I want to read eventually. I’ve been doing pretty good this holiday season, reading books family and friends gave me for Christmas (I’m such a nerd!).

JavaScript: The Good Parts. I’m reading this at the moment, and I love how condensed and packed this little book is. I especially love the appendices on the bad parts and the awful parts of Javascript. It’s pretty much a “don’t use this” list that will instantaneously make you a better programmer. Bonus: The author’s blog is also a treasure chest of anything JS-related. Be sure to check out the videos –especially JavaScript: The Good Parts, given at Google.

A few others a friend recommended are JavaScript: The Definitive Guide and Secrets of the JavaScript Ninja.

If you’ve also fallen in love with Adyy Osmani’s blog (and as a result, started stalking his genius in the world of social media), you might like his recommendation list of JavaScript books to read. He also has free ebooks and even more presentations available in his blog, but don’t mist his audio course on the fundamentals.

Blogs

If your JS craving is still not satisfied, here are a few more blogs for your enjoyment.

A list of 31 JS blogs from Stack Overflow

More suggestions from Quora

Other Great Articles

5 APIs that will transform the Web in 2013 Find out what’s new in the new version of JS (of course, I should probably call it by its proper name, ECMAScript).

A Sudden Move: One developer’s journey from C# to JavaScript

Unit Testing

Extensive Comparisons of Assertion Frameworks: BDD style vs xUnit style

Mock Type Tools: Comparison of mocking frameworks

If you are using ExtJs, Ext Spec is made specifically to mock with that library.

Bonus: a plug-in to run your tests in Visual Studio: Chutzpah

JavaScript Frameworks and Libraries

I love roundups within roundups! Enjoy!

A very extensive guide on the background of MVC frameworks and how to pick the one that will fit your needs the best by Addy Osmani (of course!)

The Big Glossary of Open Source JavaScript and Web Frameworks with Cool Names by Scott Hanselman

Tools, Etc.

Chirpy: Minify your javascript.

JsFiddle: Play around whatever framework of your choice fast!

JS cheat sheet

JSLint and JSHint: Find out potential problem spots in your code.

Frances Advincula writes the series Frances Fridays. Frances recently graduated with a degree in Computer Science with specialization in Software Engineering, she now works as a Software Developer for Accenture (Software). A proud geek girl, she’s sure she is the only one who can’t play video games. Follow her random musings at @FranAdvincula.

Tweet This Post

21 December, 2012

How Femgineers End the Year: By Becoming Better Developers

By Frances Advincula

With all this nonsense about the world ending today, I couldn’t help but chuckle at a post I saw on my Facebook feed, “I’m expecting the world to end with a bang, not a whimper.” Although we definitely don’t entertain such laughable notions, I think we could very well apply that to 2012 as it comes to a close.

This year was a big “growing up” year for me. I got interviewed at a dream company, didn’t get in, graduated, got published, moved countries, moved cities, got a ding from b-school (Please don’t ask me what I was thinking…), traveled around Asia, got into a masters program, got heartbroken a few times, lived out of a suitcase, started writing for Femgineer, ran a race, and took a job at another dream company. I actually took a picture of all the things that I wanted to accomplish this year, and when I look at it, I feel torn between feeling happy about what I did accomplish and a bit guilty, even scared about the things that I didn’t get around to, or the things that I failed at. What if I could’ve tried harder? Did I waste the last year just coasting along?

Unfortunately, all that moping around is not going to get me anywhere. I want to stop thinking about things, hoping for things, regretting things, and JUST DO THINGS. So, my fellow femgineers, in the spirit of the witty Facebook comment above, I invite you to join me to end 2012 with a bang. Do the one thing from your list that you didn’t get around to. Don’t list all the what-ifs, the could’ve beens; just do it. You don’t have to finish — just start now. Go write that book, apply for that job, start that project, join the gym, ask the boy out. Mainly for me, I wish I could’ve invested more of the year in becoming a better software engineer. In all honesty, sometimes, when I get home from work, the last thing I want to do is code some more. But it is all a matter of perspective, balance, and making steady progress. “Baby steps,” a good friend of mine likes to remind me. On that note, I thought I’d make a round up of the things we could start doing this holiday season (instead of watching re-runs of NCIS) that would make us better software engineers. If you have any suggestions, feel free to share in the comments!

Read the classics. A mentor of mine once said that one should read the top books in whatever industry you work in. I asked around the guys at work, and these are a few of the favorites. I’ve read some of these or a variation in undergrad, but I think it’s time we revisit them.

Code Complete and The Pragmatic Programmer . The first two books I honestly have never read, but the reviews say it should teach us design and programming best practices.

The C Programming Language. C is the lingua franca of all programmers, and well, if you follow Joel Spolsky, you know how he feels about being proficient in C.

Introduction to Algorithms. What makes a good programmer is a solid foundation in algorithms. Working in front-end has made me a bit rusty, so although I didn’t pick up this huge book, I did get Algorithms in a Nutshell just recently.

Design Patterns. The ultimate classic and pioneer on software design. We had a design patterns class at work, so if you are looking for a more gentle approach to design patterns, you can try Head First Design Patterns. It’s hilarious.

Clean Code: A Handbook of Agile Software Craftsmanship. This has improved the way I think about code like no other. I even wrote a summary about it here, but really, you have to read it!

Get started in open source. I planned to do this over Thanksgiving break. Instead I flew to the desert, rock climbed, hiked the Grand Canyon, learned Salsa, and did a mud run. Oh well, it’s all about balance right? But I did finally set up my GitHub account and picked the projects I want to start! If you need more convincing why we women especially need to be active in open source, you might like this article. Finally, here is a hands-on tutorial on open source “rules” and other things one must know (and cool projects in the site too!), plus a fun guide on using git.

Learn the things you’ve always wanted to learn. For me, these are the two books I’ve always wanted to read when I have time someday. Yeah, well someday arrived yesterday. I finally bought the books, so I have no excuse not to get started!

SMACSS is supposed to teach me how to architect the CSS in an application.
Granted that in my current project, I have ownership of the styling of an entire product (under the watchful guidance of a software architect), I am pumped to dig in!

Seven Languages in Seven Weeks. Mostly because I do believe exposure to different programming paradigms allows a developer to be more creative in coming up with solutions. Partially because I have always wanted to be a polyglot — nevermind that these aren’t human languages.

Be an expert in something, starting with a blog. I cannot tell you how many great new connections I have made through the blog posts I write. I had no idea people even read my random musings — my blog isn’t that great, let me tell you. However, as a professional, having a blog shows that you care about your industry enough to pay attention to trends and that you are passionate enough about the work to spend time on it outside of the normal 9-5.

From this very well-written article by Tim Ferris, “8 Steps to Getting What You Want… Without Formal Credentials“, he lists more reasons why you can position yourself to be an expert in something through a blog.

You get the education of reading practical books related to your field.
You demonstrate to potential clients/employers that you understand content related to your chosen field.
You demonstrate your willingness and curiosity to continue upgrading your knowledge in your chosen field.
You demonstrate your researching ability.
You demonstrate your writing ability.
You demonstrate your critical thinking ability.
You demonstrate your creativity.
Through your writing, you develop and demonstrate your unique professional personality and character, setting you apart from the zillions of faceless resumes.
You develop and demonstrate your social media skills.
You begin developing your profession.

Plan your days/weeks/months/life like a ninja. A friend of mine runs his life like a business, and although I don’t take it to that extreme (maybe that’s my problem?), he is a big fan of the 4th generation planner suggested in the classic book The Seven Habits of Highly Effective People. It allows you to see the big picture as far as the week goes, and your roles as a person (software engineer, student, writer, daughter, friend, what have you), so that nothing slips through the cracks. You can print out a DIY page here.

Although I am also a big fan of usual Todo.ly/Evernote/Google Calendar, I really am more of the paper and pencil type. I absolutely love this beautiful, magazine-like planner that I used to have when I lived in Manila.

Be grateful. You didn’t get to where you are by yourself. Don’t forget to take the time to show your appreciation to all the people who believed in you. Reach out to the old classmates who were always there with the can of Red Bull during finals week, to the girl who was nice to you on your first day at your first internship, to your bosses who took a chance at hiring you even though you blanked out when they asked you to do a wiggle sort, to your mentors who know when to serve you with that much-needed reality check. Whether by card, by phone call, or by email, make sure you take the time to say thank you.

Finally, don’t forget to volunteer this holiday season, to use your talents and skills to give back to your community, whether it is through a hackathon for a charity or even just helping a friend with a programming assignment or job applications. Put those skills to good use! Plus, isn’t it just so fulfilling and refreshing to be a part of something greater than yourself?

I love it how this holiday season, everyone is just eating, watching TV, and spending money. Not you. You’re starting your 2013 Year of Awesomeness several days ahead of the rest of the world. So go forth, fellow femgineer, happy holidays and have a prosperous, productive new year!

Tweet This Post

7 December, 2012

A Day in the Life of a Femgineer

by Frances Advincula

The other day, my nine year old sister asked me to teach her how to code. She loves the iPad and wants to start making her own version of Angry Birds — but with kittens. She idolizes me so, and it made me realize — jobs in tech are very much glamorized these days, and for me, that’s neither a bad thing nor a good thing. Just like any other job, there are good days and bad days. Days where in everything goes along fine, you’re on schedule, and there those blah days when you don’t feel like you’re getting anything done, and you’re just plain tired of hunting down that bug up and down the call stack.

I’m sure it is different for all of us — we all work on different teams, different projects, different companies of all sizes and cultures. But I thought I would give you femgineers a peek into what a typical day is like for me — what it’s like to belong to a close-knit team inside a giant of a firm.

My day usually begins with sitting down at my desk checking emails. I used to work in support (where the new guys have to pay their dues). When I rolled off of support and into a new team I still had to be available for all questions regarding all the bugs/issues that I had worked on. Since we have offices all over the world, I always have to check my email in the morning to see if someone has question for me. The software architect that acts as my official mentor and/or boss, the guy I work with the most, actually works from the East Coast too, so I still have to check my email to see if he has anything for me, or if the build might have been broken from a late commit from last night. I would like to not have to check my emails first thing though, as most schools of productivity teach us to avoid this, but at this point in my career, I have to.

Then I usually go grab a cup of coffee, and look at my to-do list. My todo list usually looks like a list of features that I need to make or a list of things in a feature that I need to make or a list of things I need to refactor. I have mine up in Evernote because I love how it syncs to my iPad and home computer. This is my very first BIG project so at first, I was super overwhelmed with everything that I had to. But as always, I found out that keeping a list keeps me from getting overwhelmed and keeps me focused. In true hacker style, divide and conquer!

Around 9:30, we have a spot for a code review. At least for my division, all new engineers have to have 100% of their code reviewed before it gets committed. Once you finish a task, you let all the developers know about what you did. Sometimes you also put it up in one of those review board things — but that’s all I can say without getting into trouble. Some developers prefer that the diff files get posted on a site, and they can be reviewed at the developer’s ease, but sometimes, it’s good to have all the engineers that care about that issue in a room and just bounce of ideas of each other. Both methods are welcome — it’s really up to the requester. I used to be terrified of code reviews though, I mean — hello, your best work is projected up in a screen for everyone to rip apart. But you just learn so much, they bring up approaches you’ve never thought of!

Anyway, if an engineer requests for a review that touches the product I work on, or if it’s a topic I am interested in, I attend. If they request me specifically, I go. Otherwise, I will continue on hunkering down on my to-do list for the day. I always have lots of questions, so I’ll either walk up to the other engineer’s desk or ping them. I prefer the latter, because I have this very sensitive idea of personal space, so I always ping first — especially if the developer has his headphones on. I always infer that it means, “Don’t bother me.”

My boss also told me to start writing down functional specs for myself before tackling a problem. The pages I’m working on are getting more complex. He said it will help me think through the process more, and it will force me to analyze the quality of my design before I even write a line of code. Sometimes, if you are stuck on even writing the spec, it’s great to just talk it out to somebody. Our devs love doing this with each other; they’ll just roll over to the other guy and ask… and sometimes, we talk to the dog too.

As a newbie, don’t be afraid that you are asking too much; just remember to “manage up.” Know your boss’s personality and work with it. If he likes it that you ask him right away, do that. If he prefers that you show a genuine effort of trying to figure it out before you ask him, do that. If he prefers mornings, schedule underground sessions in the mornings. Think with a win/win attitude, and everyone will get along much better and get more stuff done, which is all what engineers really want at the end of the day.

My team usually has a short standup meeting in the afternoons just so that everyone is updated. They’ve surveyed the developers before, and we all said we prefer meetings in the afternoon, when we all kinda hit that slump, and to please keep our mornings free from meetings because that is our peak time for thinking and getting stuff done. So while we are on the topic, is it a general engineer thing to dislike meetings? It seems like the more meetings, the less stuff I get done. A few of our engineers have very strong feelings about meetings, especially ones scheduled on a Wednesday, when we aren’t supposed to have meetings! Thankfully, if I feel like I’m getting sucked in into too many meetings and my productivity is slipping, I can always let my scrum master know. That usually means she can arrange it in such a way that I can skip the meetings, and developer me is happy.

If I’m working with more front-end stuff, then I work closely with the architect who loves front-end stuff, and I work with our designer as well, translating his vision into the actual thing. Sometimes, there is a tug of war between the opinions of the developers, the PMs, and the designers — and oh let me tell you, we all feel very strongly about our own. At the end of the day, though, I think that is great. Debate is great, discussion is great! It helps us make a better product.

My larger overall group also has big meetings every month or so. We always start with what we used to call “Smiley Awards” wherein people get recognized for the great work they have done. That is really something I love about Accenture Software. We really celebrate the little wins, and I have seen it make a huge difference in the motivation, especially for the younger, newer employees. From talking with a couple of my consultant friends who also work for big firms, it seems like this is something corporations frequently miss. Thus, I feel really blessed to belong to such a group. Think about it. If you’re a nobody, and yet the big bosses took the time to recognize your great work in front of everyone — well, that really raises your confidence level and pushes you to work even harder. To be even better.

If a big issue comes up, then another engineer and I will pick a room and go underground for the next hours/days until we get it done. I have to work closely with our release manager too. If a build is broken or if I need a release candidate branch merged into my branch, etc., I will go to him. When QA is testing my work, I also have to make sure I get to answer all their questions — and the same goes for our documentation team. Making a great product is really a team effort, and we all have to work with everyone, the product managers, the scrum masters, the architecture team, the UX team, the doc team, and the QA team to make sure that we deliver what we promise and on time.

If it’s a Thursday, I may have a one on one with my career counselor as well. I absolutely love my career counselor! He was my supervisor as an intern, and he feels like my dad at work — I know the guy has my back no matter what, and that he will push me to do better no matter what. We talk about my current project, what I’m doing — if I like it, if I’m learning. I tell him my career plans, and he gently starts steering my career in that direction. How cool is that, right? You get to create your dream job from where you are! We also talk about my performance goals and how I’m actively trying to accomplish them.

Sometimes, a lot of us developers in my branch go out to lunch too. It’s funny — we sit there in a table and they talk about their boats, their race cars, their hockey game last night, their wives, their kids — and then there’s me, and sometimes there is a couple of other women. Also, if it’s a Friday, we have classes in the afternoon. Right now, its Ethical Hacking and the other is Design Patterns. It’s not very formal at all, and I hope to teach a class soon!

I really do enjoy my job, and that is a gross understatement. I like that I get to work on projects that I choose, with incredibly smart people, building a product that makes people’s lives better. What’s not to love?

Frances just graduated with a degree in Computer Science with specialization in Software Engineering. She works as a Software Developer for Accenture Software. She also contributes toThe Levo League, Women 2.0, and STEMinist. A proud geek girl, she’s sure she is the only one who can’t play video games. Follow her random musings at @FranAdvincula.

Tweet This Post

30 November, 2012

What Dating Taught Me About Programming

by Frances Advincula

I feel like the geek version of Taylor Swift, rattling on about boys and such, and how “we’re never ever getting back together.” But before you judge, let me tell you how this downward spiral started. I have been toying with new JavaScript frameworks, and oh boy, am I learning by mistake. In fact, a friend and I made a list of things not to do when you are working with this framework that aren’t really obvious until you start trudging through the code. We’ve all been through this — the learning really comes when you’re neck deep in the code. Anyway, I got quite frustrated and posted on Google+ that “X framework is like dating — you know what not to do next time.”

However, before we proceed, let me first give a disclaimer: as a 21-year old, I haven’t had a vast pool of gentlemen callers, but well, I still want to write about the “lessons” I’ve learned. All names have been changed to preserve the identity of the unfortunate, I mean, the innocent.

1. The Greek, The Chef, The Med Student, and the Investment Banker. All very different guys from very different walks of life, but they all made me realize one thing: people tend to glamorize our jobs as software engineers. All these guys were great, but for the purpose of this post, all also assumed I waved a magic wand and fairy tale software appears. Reality is no such thing. In fact, the daily life of busy femgineers like us include a lot of grunt, un-sexy work like long hours of debugging, writing functional specs, pair programming sessions, meetings, etc. It’s hardly like what we see in TV with these rabid coding forays that result in a huge successes. We don’t do it because it’s glitzy; we do it because we love building products, we love challenges, and we love solving problems we thought we couldn’t do.

2. My fling with The Space Guy led me to really think about the often taken out of context quote by Donald Knuth, “Premature optimization is the root of all evil.” I mean, this guy was perfect, and half the time I’m convinced we would’ve made such a great team, and half the time, we are both like, yeah this is never going to work. Sometimes I sigh that the perfect guy — smart, kind, handsome, and handsome — got away, and sometimes I’m thankful, because OMG that guy could be a weirdo at times. And that led me to also think about the never ending question, especially for newbie engineers like me – where do we draw the fine line of making the product better than anyone else would, and still be able to ship on time? We all know that there is no such thing as “perfect software” — and especially in agile teams, there will always be room for improvement in the next sprint, but when do we know when a product is ready to ship? Does it really just come with experience?

3. The Hacker taught me all I ever needed to know about Band-Aid fixes. Our relationship was very patched up; warning flags were waving early on, but we both just kept trying to make it work, turning a blind eye to our fundamental differences. And just like relationships, band-aiding your code with hacks is dangerous territory. You know what I’m talking about — code cutoff is tomorrow, and the customer wants this bug fixed, like yesterday. Personally, when encountering situations like these, I think it’s best if we ask a more senior engineer to help us in deciding.

This was one of my more important lessons learned in my first big project. Managers were pushing for more, more, more, and deadlines were looming. I started slipping and started writing just good enough code so I can get more stuff done. Fortunately, code reviews and the right mentorship cut that in the bud. Don’t make my mistake! Remember that it’s your manager’s job to push for more, but it’s your job as a programmer to speak up about deadlines and expectations, especially in cases when you know that a solution can take a day, but the right solution can take twice as long. The bottom-line is of course you want to meet your deadlines as much as possible, and of course you always work 200%, but never ever write yourself a re-write because you hacked everything just to be able to meet your deadline. Clean code, always.

4. OkCupid taught me how to focus. I know, I know, I joined an online dating site, but really, when you move somewhere new and don’t know anybody, you really don’t have a lot of options. So I made a profile, and just like every other girl out there, I was bombarded. Flooded. Drowned. Too many prospects! And whew, going on all those dates, prepping for those dates, and heck, recovering from the bad ones took a lot of time! Thus, I realized I am kinda wasting a bunch of my precious time meeting guys that I don’t really click with (I seem to not know how to use OkCupid’s heavy statistical foundation), and it made me think about the art of picking your battles. Actually, it reminded me exactly what this HBR blog article, “Five Self-Defeating Behaviors that Ruin Companies and Careers“, says:

“Sometimes self-perpetuated decline occurs more slowly, through taking core strengths for granted while chasing the greener grass. I can’t say that this is happening to Google, a company I admire, but I do see potholes ahead — although driverless cars are an extension of mapping software close to Google’s core strength in search. But should Google expand its territory to be a device maker and communications network provider, building a fiber-optics and mobile network? This could be mission creep. Perhaps Google should focus on improving Googling.

Trying to become something you are not while there’s plenty of value in who you are can be self-defeating. For professionals, this can mean branching out into new fields while falling behind in the latest knowledge in the field that made their reputation. People can get caught in the middle — not yet good enough to compete in the new area, while losing strength in the old area.”

This is really hard for me sometimes. As a fresh grad, I know I don’t know so much, and I’m so hungry to learn everything. Sometimes I worry I am jumping around too much! I really have to remind myself to focus on the things that are most important to me so that I can actually be an expert in something.

5. The Management Consultant taught me perhaps the greatest lesson for corporate life — actually, arguably the most important lesson in life – how to manage expectations. As always, allow me to quote what I cannot say any better.

From “How Two-Career Couples Stay Happy“:

”Unspoken expectations often lead to disappointment and miscommunication in a relationship.”
“Clarifying these things up front can help you make conscious trade-offs and decisions, rather than running afoul of each other’s unspoken beliefs.”

I wish I knew this as an intern. In my first few weeks, perhaps due to my Filipino upbringing, my introvert self thought I was expected to “know my place,” and I thought it was “proper” to appear more quiet, and less aggressive in meetings and discussions because “What do I know?” So there I was, thinking I was doing just fine and dandy, until one of my bosses took me aside and advised me to speak up more. My preoccupation with “knowing my place” made me appear less passionate about the work! What if my boss never initiated that conversation? Oh, I shiver at the thought.

Remember, it might feel awkward at first, but I cannot stress the importance of talking out what the expectations are. Never assume anything. After all, how can you exceed expectations when you don’t even know what they really are?

The world of dating is not so different from the world of programming, you see, and if you’re like me, you very well know that you are already surrounded by smart and eligible peers! Well, I take that back. Coding is definitely way more awesome than dating, because unlike real life, it’s perfectly fine to do blames in Subversion, and that to me is pretty darn sweet.

Tweet This Post

26 October, 2012

My Deep Dive into the World of Front-end Development

By Frances Advincula

When I was young, I wanted to be a fashion designer. But then I grew up and realized I actually have to be able to eat food and pay rent, so I became a software engineer instead.

Fast forward a few years, and here I was, I thought, forever un-creative in that sense (I, too, rally that programming is in fact, an art. So that sense.) Until now. I’m not really sure what happened, but it seems like all of a sudden, I became super interested in the intersection of user experience and programming. I admit, I was always a bit scared to be a “designer”…Photoshop makes me nervous! But that little spot where UX meets code? Yeah, right now, that’s my heaven.

In case you’re interested in it too, here’s a roundup of things I’ve been playing with. If you have any other golden gems that you’ve come across, share them in the comments, and I’d be forever grateful!

On Designing Pretty Things

This great post in Quora lists must-read sites and books, from the classic Don’t Make Me Think to a myriad of other books. Personally, I’m currently reading Designing the Obvious, and it’s a great introduction to the fundamentals of UX. Also, here’s Joel Spolsky’s book which he posted on his blog, which of course, has great list of articles for software designers.

Besides the obvious Smashing Magazine, here’s what I’ve been sponging on.
A List Apart
UX Movement‘s list of UI pattern libraries

On Building the Pretty Things

ExtJs
Sencha ExtJs is a JavaScript framework that lets you build rich browser applications. (Sencha also has Sencha touch for making mobile apps, and popular ones include Kiva’s.) I’m dabbling with ExtJs 4, for desktop apps, and it’s been wonderful so far. Some don’t like ExtJs (and in turn rave about jQuery, but I haven’t really done jQuery, so I can’t compare.) due to claims that their API documentation is lacking and it’s hard to debug (it can be), but I have no major complaints at present. Also, I really like how ExtJs 4 is applying MVC, which I’ve found is a bit like Paris Hilton — you either hate it or you don’t.

The API can be daunting, so here is what you must know in the order that I found most helpful.
Obviously, start with Getting Started, but in Guides, this is what made the most sense to me:
Read up on the things under “Concepts.”
After you tackle “The MVC Application Architecture”, hop on to “The Data Package” which explains models and stores in depth, and then go read the 3-part series “Architecting your App” under “Tutorials”.

The articles under “Components” is good too; it should be enough to allow you to be confident in searching through the API. The video library aslo has great ones on debugging and theming your app.

Finally, here is a demo for the different types of layouts that you might find useful.

Unit Testing Your JavaScript

As you all know, I’m a big aficionado of unit testing, and ExtJs officially uses the Jasmine BDD framework. I had to do some UI unit testing research way back when I was an intern which obviously I cannot share, but I did run across this site that does a pretty good job of comparing the different testing paradigms and frameworks available.

A rundown and comparison of different javascript unit testing frameworks (xUnit style vs. BDD)
“Choosing a JavaScript Testing Framework”

Twitter Bootstrap
I took an hour intro class in this back in undergrad, and that’s all it took to fall in love with this front-end framework of javascript and LESS CSS. I loved how it’s easy to learn, and that anyone could actually making beautiful looking sites without having a degree in Graphic Design.

Appcelerator

What if I told you that you could code once and have apps that would run on Android, and iOS. Pretty cool, huh? Beloved Reader, meet Appcelerator. It allows you to code (using JavaScript) once and deploy in all mobile platforms, with just minor tweaks for the UI — a huge advantage over separately coding for iOS, Android, Symbian, etc.

I can’t stop raving at how cool this is! I mean, even the company’s motto is “Code strong.” How can you not fall in love?

If you’re curious about Appcelerator, here’s a few links:
Zero to App, a series of videos to get you up and running!
Quick Start Guide, learn the fundamentals of the platform
Building Native Mobile Applications, a comprehensive video series to get you into the “rockstar mobile dev” status!
Titanium Development, a newsletter than rounds up news and blogposts on the topic.

Tweet This Post

24 October, 2012

#1 Reason YOU Should Build a Product

I’m not sure they why the call it software, it’s so damn hard to build. In fact I’m convinced the only reason they call it software is because hardware is harder to build So maybe this great marketing tactic is what draws people into building software, and the number of those who are building is certainly growing. While I’ve been building software for 8 years, 6 in startup land, I’ve noticed a definite trend in the past 2 years, which is that there is a really high proportion of people who want to build products. In fact their desire is so great that they go to length to do things like: raise capital, hire people, and then proceed to build. But then something strange happens… they hit a brick wall, not just once, but again and again. They’re unable to ship even the first version, and after some hard work they throw in the towel and claim: “there just wasn’t a product-market-fit”. There never is and there never will be if you’re driven by a want. This of doesn’t just happen in a startup, it happens at any stage of the company, its just most prevalent in startups.

The truth is like anything in life, you don’t build products for the fame, the glory, or the exit. The #1 reason you build a product is passion. And if you ain’t got it, then you need to figure out how to get it, because honestly it cannot be taught, and this is coming from someone who wants to increase ticket sales of her Intro to Product Development class

The reason I say passion should be the #1 driver is because a lot of things will go wrong. While I’m not a fortune teller I can be certain that things will go wrong. I could even come up with a list of 100 things that I’ve personally experienced, but I need to save time and get back to building my product, so here are the top three that you need to be able to stomach:

You’re co-founder leaving you.
Running out of money.
People not believing in you and thinking you’re insane.

If you can handle those 3 then I’d say you’re good to go! The rest like deadlines slipping and losing sleep are easy by comparison. You need to use your passion for building a product to help you get through those 3+ difficult moments, and they aren’t really moments, they will feel like an era.

While passion cannot be taught, it can be harvested, and cultivated. Here’s the secret sauce: build a product you believe in. It doesn’t matter if you’re the founder, engineer, designer, or whatever in a company. You have to believe in what you are building. Its great if it solves a problem for you, but even if it doesn’t that OK. Only if you believe in the product will you want to build it and improve it. If you don’t believe in the product, you’ll concoct excuses to jump ship the minute you spot an iceberg ahead.

Discovering what you’re passionate about takes time. For some people it can be years and for others its a lifetime. While it can take time to find inspiration, I’d definitely encourage you to learn the process of building a product. That process is important.

Understanding the process, putting in place, and then falling back on it during those tough moments is how you know you’re passionate.

So if you want to learn the process come to my Introduction to Product Development course on Saturday October 27th in SF. I canot guarantee you’ll walk away passionate, but once you find it you’ll have the right process to make things happen! Use the discount code Femgineer to save 15%. Looking forward to meeting YOU!

Tweet This Post

28 September, 2012

What I Read When I Don’t Want to Code

I’m in this funk wherein I can’t code at home. I just can’t. I feel like my head needs a break from all the semi-colons.

And anyway, I’m supposed to be on vacation this week, but yet I don’t want my brain to turn into mush. I’m spending some time in Silicon Valley after all, and it’s hard not to be pumped about python and productivity and passion and pitches when one is in the area.

So this time, I thought I’d share what I do when I can’t code or read about anything too technical. Or when I don’t work on my reading list or when I don’t feel like hitting the gym like I should be. I read these blogs. Some of them are about startups, some are about life, some are about careers, some are even have tidbits on dating, but all make me feel like I’m not vegging out on the couch completely.

Elad Blog by Elad Gil. Former Googler and entrepreneur. Founded a company that was later acquired by Twitter.
A VC by Fred Wilson, a partner at Union Square Ventures. Now that I’m getting really interested in the startup scene in Silicon Alley, this blog has been quite a treat.
The Levo League, great blog and community focused on empowering young women to achieve their dreams. Love their Office Hours video feature!
Gotham Gal features a woman entrepreneur every Monday. Check it out! She also happens to be the wife of Mr. Wilson. Talk about a rockstar couple, eh?
Seth Godin, engineer turned blogger, writer, and management expert, he delivers quite a powerful punch in brief posts.
Foursquare’s former Head of Talent, Morgan Missen has everything on the intersection of tech and recruiting top talent.
Stanford’s Chuck Eesley‘s master list of to-reads. He heads the class Venture Lab – Technology Entrepreneurship, if I’m not mistaken.
Both Sides of the Table, a blog by a former entrepreneur turned VC. Guess what the author’s first job was? Programmer at Accenture!
Recommended by one of my bosses, A List Apart is a great magazine for everyone who creates on the web, design, development or otherwise.
Tough love (and often hilarious) advice on living an accomplished life as a “gentlewoman” from Jen Dziura.
Signal vs. Noise, the blog of the software company 37 Signals.
Startup Lessons Learned by the genius behind the Lean Startup movement, Eric Reis.
Joel on Software. Because if you’re a software engineer and you’ve never heard of Joel Spolsky, step away from the keyboard, please.
Orange and Bronze Software Labs. Great posts on Java, Agile, Android, Spring and Grails from the Manila version of Fog Creek Software.
Life After College by Jenny Blake. Great posts that resonate with my fresh-out of-college heart. I love how she allows herself to be so vulnerable, and yet stay so positive, when she writes.
Claudia Chan has insightful interviews with successful women. I feel like I’m being mentored by women I’ve never even met before!

But my inner programmer feels guilty, so I’m appeasing her by reading the book Clean Code – A Handbook of Agile Software Craftsmanship while I’m on vacation too. Will you guys hold me accountable? Maybe I’ll write a summary/book review on it. Yep, now I do have to read it!

Tweet This Post