How the Tech Industry Can Attract More Women Workers to Its Ranks

How the Tech Industry Can Attract More Women Workers to Its Ranks

While women have been making great strides in various industries, it seems like the computer programming sector still remains a bastion of men. Of all the computer programming jobs, only 21% are held by women.

Several factors have been cited for the small number of women among computer programmers. It has been found that among those who are earning bachelor’s degrees in computer science, only 17% are women. That’s a drastic change from the statistics in 1984 when 37% of those who were pursuing computer science bachelor’s degrees were women.

In addition, women have shown a tendency of not staying long in the industry. Studies show that among women in the tech industry, 56% of them leave their tech jobs for other industries. That’s more than twice the departure rate of male tech workers.

However, experts have argued that there are 3 areas that can work in attracting more women to the tech industry.

  1. Enabling Better Access

More women can join the tech workforce if the industry can open new pathways for women. Companies can use the popularity of their brands to increase awareness of the tech industry among women. These companies can offer scholarships for computer courses, even if these are just partial scholarships. Other companies can non-traditional graduates to enter the tech workforce by offering apprenticeships.

  1. Fostering Greater Awareness

Very few women think about getting a computer technology degree and one of the reasons is because most of them don’t even think that it’s a viable option. They don’t have enough role models in the industry, so subconsciously women think that it’s a job only for men.

Many women wish to make a difference in the world, and the computer industry should publicize how tech skills can help women make a difference. Women should also be made aware that the field is highly lucrative, and that there is a wide range of careers available in the industry. The simple ability to learn a code can enable a woman to join virtually any field in the business sector—since all industries use computers!

  1. Eliminating Self-Doubt

There are moments when we doubt ourselves. That’s universally true whether you’re a man or a woman. Yet for some reason, it’s a factor that’s noted only in women.

One basic type of self-doubt is the imposter syndrome. This refers to when we face a new task for which we feel that we’re inadequate and that we don’t belong. We feel like imposters, other words.

In moments like these, it can be very hard to cope when you feel alone. If you’re a woman in the tech industry, it’s easy to feel that way as there are very few women in the industry and the self-doubt can contribute to why so many women leave the field. However, women should seek out other like-minded women in the field through social media and corporate initiatives so that they can get some mutual support.

These areas have barriers that must be overcome so that women can find it easier to join the tech workforce. Hopefully, gender parity can be achieved even in this so-called men’s club that is the tech industry.

Author Details
Santa Monica, Culver City, Venice, Hollywood, and beyond
LAStartups.com is a digital lifestyle publication that covers the culture of startups and technology companies in Los Angeles. It is the go-to site for people who want to keep up with what matters in Los Angeles’ tech and startups from those who know the city best.
×
Santa Monica, Culver City, Venice, Hollywood, and beyond
LAStartups.com is a digital lifestyle publication that covers the culture of startups and technology companies in Los Angeles. It is the go-to site for people who want to keep up with what matters in Los Angeles’ tech and startups from those who know the city best.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Can You Measure Software Developer Productivity?

Can You Measure Software Developer Productivity?

The cost of software development kills innovation by limiting resources available to solve problems

THE PRODUCTIVITY DILEMMA

Let’s face it – software development is expensive.  Really expensive.  It’s not hard to understand why – software development is a complicated and still-maturing industry, and as the sector grows, it actually gets more complicated, not less, because of the acceleration of changes in technologies, programming languages, and toolsets.

As a technology consultant, one who is paid to help build expensive, complex systems, I should be happier than a fanboy on a Fortnite bender about this trend, right?  Wrong – it frustrates me a great deal.  My job is to solve problems and build things that people need, and that gets harder when funding becomes a challenge for our clients.

So here’s the question I’ve been grappling with – how can we make software development more productive to reduce costs?

There are lots of things our industry has done over the preceding decades to tackle this problem:

  • Developed working methodologies to build repeatable practices – Waterfall, Unified Process, Agile, XP, etc.
  • Created design patterns to solve common problems – MVC, SOLID, GoF, and many others
  • Leveraged lower cost resources through offshoring

None of these have been a panacea.  Look at any enterprise and you’ll find competing for SDLC methodologies, loose adherence to design practices, and the common efficiency roadblocks due to offshoring.  While these efforts have been helpful in managing cost, it is very difficult to measure the effect they have really had.

MEASURING PRODUCTIVITY

What to do, then?  More than anything, the focus of productivity has to start with the most human element of all – the individual developer herself.  The focus has to be on how to increase the speed that a developer can turn a designed solution into working code with as few errors as possible.

Anyone who has been in the software industry knows there are broad ranges in developers’ productivity.   It depends on the individual’s ability to understand programming theory, their educational background, years of experience, a personal situation at the time, how much Fortnite they play, etc.

Why is this important?  Quite simply, time is money.  The longer it takes a developer to code a solution, the more it costs.  In today’s environment of nearly full employment, demand for software developers has never been higher, which brings a lot of varied talent into the picture to meet the demand.  Anyone who has hired a developer knows the productivity gap I’m talking about – hiring is an expensive proposition and no matter how much interviewing you do, and you’re never sure what sort of productivity you’ll get until that person gets to work.

Why is measuring productivity so hard?  Because a good measurement involves an apples-to-apples comparison between developers, yet they will almost never complete the same task to produce the same set of code.  Since every development task is different, we cannot establish a baseline for how long it SHOULD take to perform a task versus how long it WILL take a specific developer.  Throw in each person’s differing levels of experience, education, and general abilities with the discipline, and…you get the picture.

Does that mean we’re stuck with technical interviews, coding tests, and answered prayers to create a team of highly productive software engineers?  Not quite.  Agile practices give us an opportunity to solve the biggest challenge in measuring developer productivity – creating a baseline to measure the variance between the estimated and actual time to perform a coding task.

HOW IT WORKS

Every ALM tool – Jira, or otherwise – allows a Scrum team to create story sub-tasks during their planning sessions.  Usually, a developer assigned to a sub-task has an opportunity to estimate the time it should take to complete that task, measured in hours.  During the sprint, developers can then track the actual hours spent so the team can evaluate the variance between estimated and actual hours.

This variance isn’t particularly helpful as a productivity metric because the individual developer may be much faster or slower than the average, and their estimations likely reflect this bias.

The solution to this problem is to have all the developers on the Scrum team estimate each subtask duration, creating a proxy baseline and a more reasonable expectation of the task’s duration.  Then, once a task is assigned to the individual developer, the variance calculations can start to have some meaning.

What meaning are we to glean from this variance? When looking at large sets of variances (hundreds or thousands of tasks over multiple projects), we can observe patterns in individual developers’ productivity.  If they consistently take longer to complete a task than the established baseline, we can look more deeply at the data to find root causes and potential remediations.  Is there a skills mismatch, allocation mismatch, or something else?  Does the developer need more pair programming or training in specific areas?

If a developer consistently performs tasks in less time than the estimations, we have hard metrics to reward that individual and encourage continued productivity.  We can also look at the data to see how we might have other developers emulate good behaviors from these high performers.

IMPLICATIONS

I know I know – I can hear the complaints now.  A small group of 2-4 developers on a Scrum team estimating a task cannot be used as a valid baseline, you say.  It’s a fair point, but any leftover estimation bias from a small sample size of developers would be offset by the volume of variance data we would collect.  As a manager, I care more about the variance trends and less about the exactness of anyone variance calculation.

But wait, you say.  All of this supposes a developer will be truthful in reporting their actual duration on a task.  People lie to themselves and others all the time (just read “Everybody Lies” by Seth Stephens-Davidowitz) – if a developer knows they’ll be measured on variance, they’ll manipulate their actuals to improve their perceived productivity.

Again, fair point, but there is a self-policing solution to this problem.  An employee is generally expected to work 8 hours a day.  If a developer consistently under-reports their actual durations on a task, it would appear they were consistently working less than they should be.

Say a developer is assigned two 4-hour tasks, and he takes 1 day to complete both but only reports 2 hours of actual duration for each task.  We would see a report that shows him only working 4 hours that day.  With enough data points, we could easily spot a trend of under-reporting and take corrective action.

CONCLUSION

Why is all of this important?  As individuals, not just employees, we should all strive to improve ourselves every day.  That’s how society is supposed to work – we do things, we make mistakes, we learn from them and we grow in the process.  But we can’t improve what we can’t measure.  The method I describe is very easy to implement, as long as your team is following the Scrum ceremonies.  With simple metrics and trend analysis, maybe we can finally solve a difficult problem and leave ourselves more time to knock a few more things of that ever-growing to-do list.

Chad Hahn
Author Details
Optimity Advisors, Inc.
Chad Hahn is a partner overseeing the digital & technology practice at Optimity Advisors. He is an entrepreneur with 20 years of experience in strategy, business development, operations, and technology, and has started and sold two successful service businesses. He has a strong background in software engineering and enterprise architecture, with deep expertise in both traditional and emerging technologies.
×
Chad Hahn
Optimity Advisors, Inc.
Chad Hahn is a partner overseeing the digital & technology practice at Optimity Advisors. He is an entrepreneur with 20 years of experience in strategy, business development, operations, and technology, and has started and sold two successful service businesses. He has a strong background in software engineering and enterprise architecture, with deep expertise in both traditional and emerging technologies.

GOAT is Seeking 11 Full-Time Engineers in its LA Office

GOAT is Seeking 11 Full-Time Engineers in LA

Founded in 2015 and based in Los Angeles, GOAT is the largest marketplace for buying and selling authentic sneakers. Whether you’re looking to buy rare sneakers, discover new ones, or earn money by listing sneakers you already own, GOAT is your destination.

GOAT is backed by some of the leading names in venture capital including Accel Partners, Andreessen Horowitz, Ashton Kutcher, Guy Oseary, Matrix Partners, NEA, SV Angel, Upfront Ventures and Y Combinator.

Located in the heart of Culver City, California; shared by multiple sources, GOAT is one of the best (and coolest) places to work in LA right now.

Awesome Perks:

  • Medical, dental and vision coverage
  • Daily catered lunches from LA’s best restaurants
  • Unlimited vacation and sick days
  • Competitive salary and generous equity grants

GOAT is currently seeking 11 full-time engineering talent in its LA office.

  1. Android Engineer – Seeking a product-driven Android Engineer with a strong appreciation for great design not only in products and visual presentation but also in code and technical architecture.
  2. Engineering Manager – Seeking an experienced Engineering Manager to lead a team of exceptional software engineers. You will play a key role in inspiring and driving the efforts of the engineering team to deliver the highest priority features in the quickest way possible while managing technical risk and quality.
  3. iOS Engineer – Seeking a proven experience engineer building and launching high-quality iOS apps and is excited about researching new methods or technologies that improve the architecture, user experience or engineering process.
  4. Lead Software Engineer (Golang/Microservices) – Seeking a lead engineer to coordinate and communicate across teams that span several areas of the business, including mobile, web, retail, and fulfillment Tackle large projects related to deconstructing a Rails using composable microservices and serverless components.
  5. Senior Android Engineer – Seeking a product-driven Senior Android Engineer with a strong appreciation for great design not only in products and visual presentation but also in code and technical architecture. As an early member of the engineering team, you’ll collaborate cross-functionally with product design, marketplace ops, analytics and more to ensure a solid end-to-end strategy and execution.
  6. Senior Backend Engineer – Seeking an experienced Senior Engineer to help design and implement new features across multiple backend applications. As a senior presence and a core individual contributor on a small team, you will play a key role in both enhancing a Ruby on Rails backend at the heart of the business and building out a new, more scalable service-driven architecture.
  7. Senior Frontend Engineer – Seeking a Senior Frontend Engineer to build unique websites that support both our power users and our everyday customers. Develop single page applications in React and other best in class JavaScript libraries.
  8. Senior Golang Engineer – Seeking an experienced Senior Engineer to help design and implement new features across multiple backend applications. As a senior presence and a core individual contributor on a small team, you will play a key role in mapping the expanding needs of the business into innovative technical solutions within a highly scalable and event-driven architecture.
  9. Senior iOS Engineer – Seeking a Senior Engineer who has proven experience building and launching high-quality iOS apps and is excited about researching new methods and technologies that improve the architecture, user experience or engineering process. Work with team to troubleshoot, debug, and fix issues in production and non-production environments.
  10. Senior Ruby on Rails Engineer – Seeking an experienced Senior Engineer to help design and implement new features across multiple backend applications. As a senior presence and a core individual contributor on a small team, you will play a key role in both enhancing a Ruby on Rails backend at the heart of the business and building out a new, more scalable service-driven architecture. Make technical decisions that improve the codebase while minimizing riskIdentify and fix (or, ideally, avoid) bugs and performance bottlenecks.
  11. Senior Software Architect (Golang/Microservices) – Seeking a Senior Software Architect to coordinate and communicate across teams that span several areas of the business, including mobile, web, retail, and fulfillment. Tackle large projects related to deconstructing a Rails using composable microservices and serverless components. Enhance the existing backend systems to improve overall aspects related to high-traffic mobile and web applications. Identify current and future performance bottlenecks and bugs through simulated load-testing and chaos engineering concepts

Congrats with the success Eddy!

More about GOAT

Author Details
Santa Monica, Culver City, Venice, Hollywood, and beyond
LAStartups.com is a digital lifestyle publication that covers the culture of startups and technology companies in Los Angeles. It is the go-to site for people who want to keep up with what matters in Los Angeles’ tech and startups from those who know the city best.
×
Santa Monica, Culver City, Venice, Hollywood, and beyond
LAStartups.com is a digital lifestyle publication that covers the culture of startups and technology companies in Los Angeles. It is the go-to site for people who want to keep up with what matters in Los Angeles’ tech and startups from those who know the city best.

How I Got a Programming Job in Los Angeles Bustling Tech Hub

Searching for a job as a software engineer is really painful. There’s a new tech company popping up every minute of the day, and it’s tough to know which one to choose from.

Obviously, I should be grateful for all the opportunities I’m afforded as a software engineer, and I do, but man is this an annoying problem.

The Problem

The software industry is getting a continuous flow of money from VC’s that are just crossing their fingers, hoping that 1/10 of their investments goes IPO or gets acquired.

So that means there’s a lot of cash being invested into all sorts of ideas. Some of these ideas are good, and most of them are crap. Ideally, you want to land at a company where there’s less crap.

Since a lot of these companies are popping up, there are tons of job opportunities. What I’ve found though is that a lot of these companies have hiring managers that simply aren’t prepared to interview software engineers.

These companies don’t know any better, so they use hiring practices that are popular amongst the top tier tech companies like Google and Facebook as a crutch. This makes the job interview process feel really unforgiving for new and existing software engineers alike.

I recently put myself back out there to find a new job. It’s through this long and grueling process that I figured out a few tactics that helped me circumvent many of the common software job search headaches.

Job Search Begins

I kicked off my job search for Senior Android Engineer positions back in June 2018 and started preparing for interviews. You can imagine that I’d have to be quite unhappy at my existing job to have to deal with the aforementioned job search process. Here comes all those fun whiteboard algorithms, yay.

I needed to leave my employer at the time because my goals were no longer lining up with what I was doing. This feeling is something that I’ve learned to pay a lot of attention to. It’s hard to stay excited about anything if you no longer see much value doing it.

My short-term goal at the time was relatively simple: be part of a product-oriented team at a company that focuses on software. Additionally, my long-term goal has been to become a better leader, so I can one day confidently lead teams of my own.

With these goals in mind, it really helped me filter out the job opportunities that were presented to me.

Finding Opportunities

Having been so disappointed with previous job search processes, I desperately looked for a better way to interview with companies. That’s when I came across this very eye-catching ad while I was perusing Quora. It said something like “skip the whiteboard interview”. I was sold.

I am thoroughly convinced that the whiteboard interview has caused more people great pain during their careers as software engineers than helped hiring managers narrow down candidates. It’s one of the most anxiety-inducing and demoralizing interview “strategies” I’ve ever experienced.

Whiteboarding is a topic I could rant about for hours. It was my main motivator for finding a new way to job hunt, and this anti-whiteboard ad I found for a company called Triplebyte, was my holy grail.

I applied for their developer exam immediately. Since I’m an Android developer, I chose their mobile specialty exam and raced through the timed questions. I soon got confirmation that I was good enough to get a follow-up interview, and went from there to schedule it.

The whole process, from initial exam through to their video call screening, and eventually to the onsite interviews was fantastic. I really felt I was getting taken care of. This is how interviewing should be!

That wasn’t the end of my interviewing journey though; it was really just the beginning. Even though Triplebyte set me up with five great companies to interview within San Francisco, they didn’t have the clientele at the time to help me search more local. Since I live in Orange County, I had to find job opportunities out here the more traditional way.

I reached out to everyone in my network that could help me out with this. Previous co-workers, friends, family, and anyone else who could point me to a company with the values I was looking for. I set my LinkedIn profile to “searching for a job”, and tidied up my resume.

I got into contact with a few different interesting companies this way. Some in LA, some in OC, and more — many more — in the Bay Area. I really didn’t want to have to go to the Bay Area.

Besides the obvious factors of the Bay Area — like it’s way too expensive — I knew that moving there would be tough for my wife. It would be much easier to be able to pack everything up and move up there with all the industry elites if I was just a single dude. I had to think about my wife’s family, my family, and the future we’re trying to build together.

That said, I knew that I wanted to get as much interview experience as possible. From previous interview experiences, I anticipated a certain ramp-up time needed to get my mind warmed up for the oncoming onslaught of interviews. The more interviews I got through, the better I felt about the next one.

I ended up narrowing down my search to seven companies: one in LA, one in OC, and the five Triplebyte had arranged for me in the Bay Area. It was time to buckle down, so I took a week off from work and got ready to dive deep into my interviews.

The Interviews

Triplebyte’s process promises that once you are through their initial screening period, you’ll skip ahead to every company’s final interview.

Every company evaluates their software engineers differently. Some throw many hypothetical and theoretical technical problems at their candidates, whilst other companies stick to more practical job-related interview questions.

One thing that really stuck out to me in my round of interviews is just how inconsistently the idea of a “Senior Developer” is defined. Some companies have a list of skills they expect from their “Senior” people, and others just want to see how many hoops you can jump through before getting to the real work.

This made me realize just how fluid job titles are from one business to another. A “Senior” developer at one company could very well be a “Junior” developer at the next one over. Title definitions all come down to the business’ needs, their existing pool of talent, and how desperate they are to hire developers.

Having caught on to this very strange phenomenon, I knew I had to problem-solve my way out of it. So I started explaining to companies what I thought was “Senior” to me. I made sure to highlight my experience leading teams, my abilities outside of programming, and of course proving this all via different code challenges and Q&A.

It actually worked. Of course, the caveat here being that my strategy only worked on companies that I could truly add value to. Meaning that I had to have already been a solid candidate; I just used my “Senior” story to help tip things in my favor.

Out of the seven companies I interviewed with, I received offer letters from five of them. It’s not a bad batting average at all, and I felt rather proud of myself for getting this far.

It wasn’t long after my interviews were over, however, that the final challenge would prove to be most difficult. I had to make a choice as to which company to go to.

Making a Decision

I was staring at a list of five incredibly impressive businesses, with similarly incredible offers. I took a tip I got from one of the recruiters and started on a spreadsheet with all the companies I was considering.

I ended up with a whopping seventeen different categories that I used to compare all of these companies. Let me say that this helped immensely. It gave me a high-level look into all the things that I cared about. Here, I’ll list them out so you can laugh at how thorough this ended up being.

The categories in no particular order: pay, equity, 401(k), relocation bonuses, benefits (like medical), extra perks (like lunch catering, cell phone allowance, etc), vacation policy, company culture, engineering culture, product pros and cons, social impact, audience size, industry, gut feeling, location, commute, and work hours.

The Winner

All things considered, I ended up at my current employer, Weedmaps! I honestly surprised myself at this one too. I’m not a cannabis user, but I was so impressed with everything they were offering that I felt like it was a no-brainer to me.

What really tipped it in Weedmaps’ favor too is that I didn’t have to move. I could stay in beautiful OC, and be close to all my family. I think that’s something that people don’t value enough when considering their next job.

So far though, I’ve been thoroughly pleased with my choice to work at Weedmaps as a Senior Android Engineer. Having been here for just a few months now, I’ve really grown to enjoy working here. I’m so impressed with just how welcoming, and collaborative of an environment Weedmaps is.

It’s the collaboration, the willingness to compromise, and the desire to be better that makes a place like Weedmaps feel like home to me. I think those three traits are what foster growth, and build great teams.

For now, I’m focused on really maxing out the value I can bring to my team at Weedmaps. It’s a place that I feel will grow with me as I continue to push towards my career goals.

Maybe next time I can talk more about those dreaded whiteboard problems. Sigh.

Check these 50 Hottest LA Startups to Work For Right Now

Ryan Simon
Author Details
Ryan Simon is a Senior Android Engineer for Weedmaps. He has taken his background in investing, his degree in business and applied to the world of a software engineer. Ryan spends his free time cooking with his wife or playing Overwatch.
×
Ryan Simon
Ryan Simon is a Senior Android Engineer for Weedmaps. He has taken his background in investing, his degree in business and applied to the world of a software engineer. Ryan spends his free time cooking with his wife or playing Overwatch.
Latest Posts