Blog

UK Black Business Show 2018

On 13th October, I went to Westminster to the Queen Elizabeth II Centre to attend the UK Black Business Show 2018.

I was excited to go because if you’ve been following me for a while, you know I’m trying to learn and grow as an entrepreneur. I find that when I go to conferences, I’m more inspired and ready to focus on this topic when I leave. This event was no different, in fact, it gave me a lot more confidence in what I’m doing and motivation to keep going and keep growing.

Unfortunately, I learned about this event very late. My mum had bought a ticket only to find that she want able to go because she was flying back from a trip at this time. So she offered the ticket to me. I didn’t know what to expect from this event, but looking back, I’ll be sure to be buying a ticket for next year and telling all of my friends (no matter what their ethnicity) about the event.

There were lots of motivational words from all the speakers and inspiring individuals on the day but, I want to write this post to capture the points that were key to me. I want this to post to remind me of the key ideas and thoughts that spoke to me through the day so that over the next six months I can refer back to it and relive the thoughts that inspired me that day.

Talks and Notes

Andrew Ramroop: A Journey from Pillowcase to Buckingham Palace

  • What makes my products or services stand out from others?
  • How is my product standing out for something that’s different?
  • What makes my service/products better than the competition?
  • Why should customers engage with your services?
  • What makes you outstanding?
  • Train all year round not seasonally.
  • To make a world class company, keep in mind that you need:
    • World class standards
    • Business standards
    • People
  • Make the customer your top priority
  • Your mission statement should state who you are and what your do

Olutayo Arikawe: Making An Impact: How to Use Your Profession to Benefit Your Community

  • Give to your community and your business will thrive
  • Take care of your staff and your community

Fredi Nwaka: Journey to Hollywood

  • What is for me is for me
  • Network to get work

Ronke Lawal: Why Marketers & Brands Need To Engage Black Women

  • £300 Billion black spending power in the UK – IPA
  • Don’t under value yourself
  • Think about the money
  • The love of money isn’t a bad thing

Rashada Harry: Creating Diversity in Technology

  • It’s not what people listen to but what you answer to
  • You have two hands, one to help yourself and one to help the person behind you

Kubi Springer: How to Take your Brand Global Marketing

  • Be an expert
  • Be known for one thing
  • Tell people what you can offer
  • Go in with the numbers and stats to investors. Let the money, numbers and stats talk
  • Get IP in place
  • Stop doing a business for the short term
  • Be Globalised

David McQueen: Building A Legacy in Business

  • Give back to the community
  • Stop comparing yourself to others. Work as hard as your want to work
  • Not enough people build for legacy
  • Build businesses that run without you
  • Build systems
  • Think bug. Stop thinking small
  • Why are you building a business?
  • What are your values?
  • Ideas are crap. You need customers
  • Stop giving things away from free
  • Stop selling out. Think about how to take it to the next level

UKBBS Dragon’s Den Pitching Advice

  • Knowledge
    • know what you’re talking about
  • Work your time
    • Brand background
    • Where are you right now
    • What have you done so far
    • Where are you going in the future
    • Money
    • How to get more customers
  • How are you going to build a company & legacy
  • Look at the numbers
  • How are you making money
  • Think big
  • Scale up
  • Make that money
  • Make your people feel that you deserve the money that you ask for
  • Give the business talk first, then the passion talk second
  • Breakdown how you’re going to make that number
  • Know your numbers
  • First impressions count
  • Presentation
  • Visual identity
  • Tie how you’re dressed with your company brand

When Resource Ids Are Not Recognised In A CS File

I’m using Xamarin Android for one of my current projects and (especially after my recent short break) sometimes I forget important lessons that could leave me confused and annoyed for ages.

Here’s an example of one of them:

Sometimes you need to create a new component in your axml file. You add an id and the rest of the parameters. Then you want to create the event that this button will call once clicked. So you go to a CS file, create a new variable to hold the resource and proceed to create a new event. Then the compiler catches up and you see a little red squiggly line under your resource id name 😩

Why Does This Happen?

The Resource Library is searched for the id of the new component when the code is pre-complied. The Resource Library is a file in the Android project listing all id’s of your components declared within your axml files. If the id of the component mentioned in the CS file doesn’t exist in the Resource Library, then this is highlighted as an error.

Resource Id Resolution

Comment out the use of the resource in the CS file, then do a rebuild of the project. After that, uncomment the reference of the resource in the CS file. Voila!

Reason

The new resource needs to be added into the Resource Dictionary before it’s used in other files. By commenting out it’s usage in the CS file, when the compiler checks for the resources, it won’t find it anywhere and will continue to add it the Resource Dictionary correctly without freaking out.

Coding is part banging your head against your desk, part shouting at your computer, but mostly (hopefully) part fun. It’s the fun that expires me and keeps me going when I hit those coding walls of despair. But I keep hope alive because I know I can get over it…eventually! If you code something everyday, you’ll start to hit these walls less often.

Don’t Be Afraid to Pivot

Running a startup and working within a startup, I’ve learned that you have got to make decisions quickly.

When opportunities arise, you must think strategically for the long term and re-prioritise, change or even cancel your projects in order to seize those chances.

Always keep in mind what your long-term objectives and goals are. If you’ve been presented with an opportunity that will move you closer to your goal, then take it. If you’re a bit apprehensive, you could draw out a SWOT diagram or a table of positives and negatives to figure out your next move. But at the end of the day, the goal is to keep moving forward, so don’t let a lack of experience, lack of faith in yourself or lack of time stand in your way.

Make it happen and pivot! You can always finish what you were doing after you complete this little detour from your initial plan.

Tech Girl Issues #2: VR and Mixed Reality Headsets

I’m not just about my hair and nails, but if I take the time to look nice in the morning, I don’t want my efforts wasted by headsets (or any tech equipment) that I need to use everyday to perform my job.

As a woman in a development role, I’ve gotten used to the fact that I’m probably going to be the only woman within my team (and maybe the office depending on the size of the company). But to be honest, I don’t even notice things like this anymore, except when I’m actually using tech.

I enjoy the fact that I have an active role in the development and also the quality of the product that we deliver. I wholeheartedly believe that we need more females in development roles because we do think differently. And these differences will be reflected in the products that we eventually turn out.

So when I come across new innovations in tech that don’t seem to be designed with the other 50% of society in mind, it makes me slightly annoyed and disappointed.

We all know how important it is to ensure that your end user gets their hands on your product before you release, because if they only get it once it’s mass produced, it’s extremely expensive to recall and fix the problems or to teach the users how to use it.

The Tech Devices

Vive Pro

When HTC released the Vive Pro, we were lucky enough to get hold of a first version of the upgrade. And I wondered, having used the Vive Pro and the original for about year, does HTC even test these devices with a wide range of women?

With the high price point of these devices.you would expect it to be of a pristine quality and suitable for everyone, male and female who wanted to use it.

Now don’t get me wrong, out of the all the VR devices I’ve used in the last 18 months, the Vive Pro is actually one of my favourites. Plus being one of the first companies to produce a high end VR device must be hard without prior tech to build and extend. So I say this in the hopes that HTC amend they’re testing and development workflows so that they can gain more loyal customers.

Challenge 1: It doesn’t play well with my natural hair

With the first released version of the Vive, yes it’s heavy especially if you wear it as much as I do on a daily basis, but it’s comfortable. Except for when you want to take it off. The velcro on the headset is constantly catching my hair ripping out hard-earned growth. Then we come to the fact of what my hair actually looks like after removing this headset. Let’s just say if I tried to fix my hair after every time I took the Vive off, I’d probably lose an hour of work a day!

To get around this problem, I’ve resorted to either having to wear specific hairstyles that won’t need to be redone after constantly putting on and removing the headset or just give up and deal with the fact that I won’t have a tidy head of hair on my head throughout the day.

Challenge 2: Gives me a slight pain in the head

Now with this new and “improved” headset, although it’s supposed to be lighter, I’ve found that after about ten seconds I get a pain on the side of my head. This may be because I have a weird shaped head, or a small head but when I put the headset on, I adjusted to what I thought was suitable so that I could work. And this caused me pain. Should I need to be told the best way to put on a headset or should it be intuitive? The latter right? But, this is my job, so I’m going to have to figure out why the headset doesn’t like my head.

Note: After using the Pro everyday as my sole dwarfing device for VR, I don’t get this pain anymore. I’m not sure if my head’s gotten used to the weight or I’ve found a better fit, but I’m happy this is no longer a problem.

me with braids

Challenge 3: Braids don’t work either!

So as I’ve just been to Italy, I didn’t want to have to do my hair in 35°C+ heat everyday for two weeks, so the week before I got braids put in (the stickers on the back of my phone are the latest additions by my three year old daughter).

This was supposed to make life easier for me on holiday, but it didn’t at work. I don’t put my hair on any style extravagant, just up in a ponytail to keep it out of my face. But when I first tried to put the Vive Pro on I found that this wasn’t going to happen in my current style. So in order for me to test, I have to remove my hair band and put it back in when I’m finished every time. Needless to say this slows down work, but luckily it’s only temporary. But again, I’m reminded of the fact that this probably want accounted for during the design phase. I suppose the ”workaround” of taking my hair band out works, but should I have to use it this way? In 2015, 15 percent of males versus 8 percent of females had tried VR devices so to cater to the majority of users makes sense, but only at the expense of crafting a further barrier to entry for females.

Mixed Feelings with Mixed Reality

I’ve switched projects now and I’m using a Samsung Odyssey for testing. Overall, the device is nicely designed and light compared to other VR alternatives I have tried. And, I haven’t had the pain in my head when I first tried it like with the Pro so I’m happy about that. But, I still have the issue with my hair 🙁 I don’t think this is going to be a problem that’s solved anytime soon unfortunately. But I’d love to know the following things from HTC and Samsung to help me understand how they got to these design decisions:

  1. The percentage of testers that worked on the Vive products that were women?
  2. How many women HTC used during user testing of the Vive and Vive Pro?
  3. Did they choose a range of ethnicities?
  4. Did they even perform user testing?

Surely, I can’t be the only one that had these hairy (see what I did there?) issues? Maybe these issues were raised and were deemed minor or not a bug? I don’t know, which is why I need answers!

It sounds like I’m asking a lot, but for a global company like HTC and Samsung to roll out a product, you’d expect that they’d cater for the global audience. I mean, if a woman in her 70s wanted to start using her child’s or grandchild’s VR kit, why should there be a barrier for her?

Going Forward

I’ve used a few VR devices and they all have some accessibility issues. Making these products usable and comfortable for all users will increase the market reach, increase loyalty to the product (and possibly the brand) which would increase sales. So, why not invest more time into testing with a wide range of users to build out products that appeal to more customers?

Please consider this HTC, Oculus and Samsung. My hair and head would very much appreciate it.

What You Can Learn From Contract Jobs

I’ve just completed a contract app project. And although I’ve completed and shipped projects to app stores previously, there are significant differences in the workflow and processes that make these types of jobs more complex.

For starters I’m working with other people so expectations to deliver are higher, working builds are essential and completing to the agreed deadline goes without saying.

Here are some of the things that I have learned over this recent contract project and what I’m planning on implementing in my development practices going forward to improve my skills and workflow.

The Contract (or Client Agreement)

After discussing ideas with external clients, contracts, client agreements and non-disclosure agreements usually come into play.

This is a standard part of working with any client as they want to ensure their work/idea is protected and you want to make sure the work agreed is scoped correctly, all deliverables are defined and clear to both sides, and if this keeps the client happy all the better.

I’m not a professional working in the legal sector so I must state that you should consult a legal professional in your area to make sure any contract you sign is acceptable.

While most standard contracts should be sufficient and simple, it’s important to make sure the contract covers all details. For example, you may want to make sure that the payment date is determined by the work being delivered and not when the project is being used or released.

Freelance Jumpstart had a great podcast episode for this topic. I would encourage you to watch or listen to this to make sure you include any additional points into the contract you sign.

Project Scope

The project scope should be laid out in detail before the work begins. I provide a quote to the client before hand detailing all features requests and the cost of each. So when it comes to the contract, you can reference this document or include it’s contents to the project scope section.

Handling Feature Creep

Feature creep may come from a client trying to build a better product, or it may be it you getting excited about the project and adding in lots of additional bells and whistles that weren’t even necessary (believe me we’ve all been there). Another way feature creep can occur is from reviews.

To ensure you stay on track with development, after every meeting, write a summary email with the meeting outcome. It’s important to detail here any changes to the project scope or deadlines that will be incurred due to these late feature requests. But the best thing to do is to state that although these would improve the project, they will also add additional time to the project length and may mean the project deadline will have to be extended.

Depending on the client and their deadline will depend on whether you add these changes in or not. Remember to get acceptance to deadline changes in writing.

Supporting Documentation

You may not have factored in writing these documents when doing your initial quote but be wary that these documents are essential for your client so they need to be done.

So if you add in a feature for e.g. analytics don’t forget to include a charge for the report creation into the cost.

Project Management

Whenever you begin a new project, it’s important to outline your development process so that both you and the client are in the same page going forward.

If your project is across a few months, I would recommend setting up weekly milestones in the form of calls, emails or in-person meetings with the client to show progress. State this in the development process mentioned above so that all parties know when to expect these.

Verify at the beginning of the project to find out if the client thinks this is too frequent and adjust accordingly. A weekly meeting will also help you as the developer to ensure progress early and often.

Release Candidate Build

A release candidate (RC) build is what I call the build that you have produced which you have implemented all of the features and are ready for user acceptance testing. This may not be but free, but it’s feature complete. Any bugs found in this build should be fixed and a new build created.

Put in a RC deadline into your calendar a week or two before the contract deadline. This will make sure you deliver on time and factor in working on bugs during the contract length.

Project Support

This is something you’ll have to negotiate with your client. After handover (or whenever the client begins using your project) is the time when they may need the most support. Be prepared to support the project for about two weeks after handover, but make sure you have this as an optional additional cost in the contract. If you’re planning to be away during this time, bring a machine to debug and build on in case unexpected bugs arise.

Images

When working with artists, request images in the correct sizes for each dpi folder. Or, if you’re willing to invest in some additional tools, you can also use mfractor’s Import Image Wizard feature.

For Android projects, these are the recommended sizes. For iOS projects, these are the recommended sizes.

Make sure that the images are also named in the correct naming convention for the platform or they’ll get rejected at compile or build time e.g. Android shouldn’t have uppercase characters or symbols other than underscores and can’t end in a number.

New Tools and Software

Working on a contract project instead of my own personal projects is a great way for me to stretch my own skills. For example, in this project the client had certain features that they wanted to implement, so this made me investigate using new tools and software that I maybe wouldn’t have chosen to use for my own projects. Doing this stretched my knowledge and has definitely helped me and my confidence grow.

The Good That Comes From Pushing Your Limits

I encourage everyone to work on a paid contract every now and again. It forces you to bring a higher level of professionalism to your work and when you’re at that level, you don’t want to go back to “anything will do to get this out”.

Lastly, I would advise you to try and accurately estimate the work you need to spend on implementing your features. If you find that a feature has taken half an hour to implement rather than the two that you estimated, move onto the next task and do something daily. Doing this early in the project will lead to more productivity and hopefully no crunch at the end.

Never crunch!

This post was exported in one click from Google Docs into WordPress with Wordable.

Tech Girl Issues #1: Smartphone Keyboards

I consider myself someone who embraces new technology, games consoles, smartphones, tools or software. From a young age I’ve always had an interest in tech which has followed me all through life so far. But time and time again it still happens. I come across examples that make it obvious that this product that I enjoy or spend a lot of time using was not designed for me or with me in mind.

This week, I recall a particular issue that I has when I was buying my first smartphone.

Smartphone Keyboards

IMG 20180826 WA0002

In 2010 I decided to let go of the monthly phone contracts and upgrade to a two year contract. This would allow me to get my very first smartphone. HTC Desire was the first smartphone I tried in Carphone Warehouse but I soon came across a big problem.

I liked the size and look, but typing using the touch screen keyboard was particularly difficult. The main issue I had was that my nails were preventing me from using the keyboard. This was because I was trying to tap the buttons using my fingertips.

Now you can see in the image, I don’t have particularly long nails. I’ve also never had the lengths that false nails provide. But every few weeks after they’ve been cut, my nails reach just over half a centimetre. It’s at this point I tried using the Desire and I thought “if I’m going to have this problem every few weeks, then my life is going to get more difficult, not less with this device!”.

Let’s Try This Again

Seeing my annoyance and frustration, the sales assistance presented me with another option. He then brought out a Samsung Galaxy S.

48201652044PM 635 samsung galaxy s

Why did he present me with another smartphone after I obviously wasn’t getting along with this first one that was, at the time, the best selling? It was because of a small piece of software pre-installed on the Samsung Galaxy S devices called Swype.

Now I guess I would’ve experienced this problem with all smartphones, but only the Galaxy S had the Swype software to remedy this problem.

After he explained how to type using this feature, I was so happy. I signed the contract straight away and went home to show my husband. He was pleased for me, but not for him because he’d already purchased HTC Desire which didn’t have this fabulous feature.

I know it seems like a small thing. But, if I never was introduced to Swype, I probably would’ve stayed a smartphone virgin for a couple more years. This small limitation excluded purple work long nails and generally that’s women. Yes, we could cut our nails, but should we have to in order to use the product?

Since the introduction of Swype, it was available on any other Android devices via Google Play. Then Google even put their own swipe feature into their Google keyboard. And, amazingly, in September 2014 following the release of iOS 8, Apple opened up it’s keyboard platform to allow developers to create custom keyboards to introduce Apple users to the magic of swiping instead of tapping keys.

We Need More Tools Like Swype

swype keyboard 1519114223534

Swype had reduced the barrier to entry for me and I’m sure a lot of others with long nails. But there’s one thing I want to draw attention to. There shouldn’t have been an additional tool available by a third party company solving this solution. The phone manufacturers should’ve considered this when designing the phone and came up with their own solution. Reducing the barrier to entry for those with long nails may have introduced a lot more women into smartphones earlier than they did.

These days children have smartphones a lot earlier. Could this have been a way to change the way women and young girls thought about mobile phones. Maybe getting them into using it earlier would open their eyes into the possibility of creating with these devices?

Who knows, but it certainly wouldn’t have hurt.

This post was exported in one click from Google Docs into WordPress with Wordable.

Get Up And Code Something Everyday

Being able to code something everyday is a great way to improving your development skills. Just like Jennifer Dewalt who built 180 websites in 180 days, you will slowly notice your skills improving. Things that you may have struggled with to begin with becoming easier.

The journey to building great development skills doesn’t happen overnight. I have to always remind myself of this fact. It takes time, lots and lots of time! Doing something small and short everyday helps you keep up your momentum, moves you forward little by little and keeps you motivated.

Speaking Up as a Woman in a Male-Dominated Tech Team

Here’s my next post which appeared first on Simple Programmer.

Since university, I’ve been in work environments (and sometimes geographical locations) where I’ve been in the minority in terms of ethnicity and gender.

It’s been this way for so long now that it usually surprises me when I see more than one woman in the office or on the team at the same time as me.

Therefore, I’d like to share with you, especially those female readers out there, the journey I have gone through in becoming a more outspoken person at work and other situations.

Yes, probably not all of these are specifically “female only” issues, but I can only speak from my own experience.

I’m sharing these thoughts with you so that if you’re currently going through this, you know:

  1. It’s not your fault.
  2. You’re not alone.
  3. You can get through it.

I hope that my experiences will help other females find the courage to speak up more in the workplace or other male-dominated environments and situations.

My Early Experiences

As I came from an all-girls secondary school and sixth form college, the change in gender ratios upon entering university took me massively by surprise. What was worse was that boys would make friends instantly, calling each other “mate” until they were friendly enough to ask each other their actual names.

Being in this new balance of males to females, I quickly noticed a few things. One, because of the very small number of girls in my course, I had no one in my seminar groups to bond with and hardly anyone in the lectures.

Two, the boys didn’t seem to engage with me in the same way they would befriend a new male and integrate him into the group. Looking back on this time, maybe this was due to the fact that I was in a computing course with a load of boys where some or most weren’t used to interacting with women regularly, but at the time, this wasn’t obvious. And since I was by myself and far from home, being left out wasn’t a pleasant feeling.

Because of the lack of women in the tech industry, we are more likely to second-guess ourselves in situations where we are the most experienced. We don’t shout about our achievements and don’t claim our individual successes. So in order to make sure I wasn’t stuck in a course, speaking only to myself for three years, I chose to learn how to speak up.

Why It’s Important to Speak Up

I currently work as a QA and Release Manager. Day to day, I have to ensure that the projects we produce for our business and platform users are of a high standard.

I carry out manual testing and write automation scripts to alert the developers as soon as possible when their features are broken. Besides this, I communicate with product managers to get accurate acceptance criteria, and I make sure the product’s features align with the business values.

When testing, I also need to speak with developers and DevOps engineers regularly. Every so often, I also speak with the “chiefs” to update them on issues that may affect the quality of the business products at a high level.

So, I do a lot of talking and listening every day. It’s important that I can confidently engage with everyone, from the CEO to developers, so that my point is heard and taken into consideration.

If I’m not able to speak up about the issues that I find or convince others about my opinions, then customers could have a bad experience. This could negatively affect the company’s brand and impact their finances in the long term.

If you speak up and show that you are capable of getting your point across, you will portray a stronger, more confident self. Therefore, the sooner you learn how to say something, the sooner you’ll be listened to and heard.

Obstacles I’ve Faced

I have come up against a number of challenges, and they have not been easy to face or overcome. To be honest, feeling at ease about speaking up has a lot to do with your team and company. Knowing that you’re in an environment that’s not judgmental is key when you’re trying to overcome these challenges.

But you won’t always get to work with these “golden teams.” Here are some of the things I experienced when I didn’t feel like I was working with that “golden team” and what I learned as a result.

When You Think of the Answer First

It’s the usual weekly meeting “X” with the team, and you’re discussing the best way to solve a problem. After taking a few points in and using your own knowledge, you come to a sensible suggestion, but you stay quiet. The team goes on for another 15 minutes discussing the solution.

Then suddenly someone else will exclaim the same idea you had. You’re happy because you were right, but you kick yourself because you regret not saying it.

Lesson: Even if you aren’t sure it’s the right solution, speak up and say what you think. Your teammates are not mind readers, so you have to help them hear your thoughts. And if your idea solves the problem, you could save everyone time and build your credibility at once.

When You’re Not Confident in a Group

Imposter syndrome affects a lot of people, male and female, but I’ve found that it especially affects women within the technical fields.

Feelings of self-doubt and fraudulence can strike, for instance, when you’re in a small group of developers. You may not feel like you can contribute to the discussion for fear that you’ll be wrong, and then they’ll find out that you don’t know as much as you seem to. You’ll be laughed at for saying something stupid, and then you’ll be fired, fall behind on your mortgage payments, and lose both your house and your partner.

OK, that’s probably getting a bit extreme, but that’s generally what people have in the back of their minds. Your team or employer will find out that you don’t know everything and will think badly of you. So instead of speaking up, you stay silent in the hopes that no one discovers your “secret.”

In reality, this never happens. People on your team are generally more forgiving (and feel exactly the same way as you). The only thing that actually happens is that you don’t grow.

Lesson: Say something, no matter if it could be wrong. Practice engaging within a group to learn more than you currently know. Asking questions and giving your opinion is generally something that’s not going to negatively affect you.

When No One Hears Your Answer

Another situation could be when you’re in meeting “X” and you drum up the confidence to express your idea, but no one hears you, and they continue talking. You go quiet again and continue to listen to everyone’s comments. Then after five minutes, someone has an idea that’s exactly the same as what you said previously, and you kick yourself again.

Lesson: If this happens, don’t shrink back. Remember that the fact they didn’t hear you was most likely accidental.

You need to think about why you may not have been heard. This may be for a number of reasons, for example:

  • There were too many people in the room speaking, so they couldn’t hear your voice.
  • You said it too quietly to be heard.
  • You’re typically a soft-spoken person who may not be easily heard all the time.

Try hard to shake off whatever you’re feeling about this, gather your confidence, and say it again but louder and clearer, making sure that everyone can hear you.

When Your Answer Gets Dismissed

This last example is not very pleasant, but it can happen, so I thought I’d share it.

You’re in meeting “X,” and you are quite confident about the subject being discussed. A question is asked, you give your opinion loudly and clearly, and it’s even a possible correct solution. But you get shot down by the person leading the meeting. However, when another person says the same thing, they are praised for their idea.

Lesson: Note the times, dates, and situations where this happens. Then report it to your manager and/or Human Resources department as soon as you can. This may be a pattern with a specific individual. The stifling of anyone’s opinion should never be tolerated in any company.

Get the Team Used to Hearing Your Opinion

The only way to overcome these situations is to give your opinion whether or not you know it’s right. The idea is to get used to speaking clearly and confidently.

Don’t let people who have opposing opinions when discussing your ideas catch you off guard and shake your confidence. They’re not (always) doing it to challenge you negatively, but they are doing so constructively, making sure your ideas are truly solid. Discussion about your idea confirms that you at least are being heard.

Lastly, you want to make sure you’re not too forceful with your opinion. Be strong and confident, but not arrogant. It’s a fine line, and some people may only see you as bossy, arrogant, or bitchy no matter what you do.

Make sure you identify these individuals and take what they say with a grain of salt. Don’t let them shake you.

Face Your Fears Little by Little

When I first entered these environments, this gender imbalance made me a lot less confident and unsure of myself. Sometimes, this can be misconstrued as you not knowing what you’re talking about rather than your being in an uncomfortable situation.

And unfortunately, for some men in high up roles, this can be abused further by talking down to you, making you feel less confident about your suggestions, and even dismissing your ideas when you do drum up the courage to say something.

I’m here to let women who are in the same position as I once was know that this treatment is not OK. The only way to make yourself heard is to speak up. Speak up loudly and confidently.

This is still a personal journey. Some days, I don’t want to be talkative (which usually suits my developer colleagues, who want to get in the zone and code all day, just fine), but I still need to push through and complete my daily tasks.

Sometimes I make mistakes and say stupid things, but I’ve learned to pick myself up faster and get better each time, and you can, too.

Like anything worth doing, it takes hard work and practice. And remember, you’re worth being heard.

How My Soft Skills Have Improved While Working In A Charity

Soft skills, like good communication, listening, personal organisation and being able to teach others skills, are attributes that are sometimes harder to teach than technical skills. This is because soft skills are part of a person’s day to day life from when they are little and are ingrained into their behaviours. Therefore, it takes more time and focus to change the behaviours for your soft skills.

I’ve noticed that one easy way to be intentional about how you learn to change your habits is to put yourself into situations where you are forced to adjust the behaviours. I think that I’ve improved my soft skills through charity work.

I have been volunteering at the Lignum Vitae Club (LVC) charity since 2013. LVC was started in 1969 by the Jamaican High Commissioner’s wife and it’s mission is to support charitable causes which provide education and skills training opportunities for disadvantaged children and young people from Jamaica and the UK.

I decided to join the club because I wanted to help give back to the country of my heritage and help support other charities doing good work in relation to Jamaica.

When I began volunteering, a lot of the members were at least 27 years older than me, especially those on the Executive Committee. I’m a millennial and have grown up with tech. I easily adapt to and learn new software, trends and hardware. Because of this, I became the “technical guru” of the club.

But at times, it was hard to convey my new ideas using technological advances to people who didn’t understand it or the benefits. This is where I believe my soft skills have improved.

Here’s a short list of the skills that I think I’ve improved so far:

Communicating My Opinion

I’ve learned to be more aware of my audience when talking (my husband does tell me that I speak fast). So when I’m in a meeting explaining my view, opinion or new idea I make sure I communicate clearly and slowly, and to try not be sound condescending or in a way that can be construed as that. Because of my job and what I enjoy doing in my spare time, I pick up new skills quickly but I need to remember that what’s easy to me, may not be easy to others. So clear communication is key.

Speaking About New Tools or Technology

Another aspect of communication is being able to explain my ideas to implement to a non-technical audience. I’ve have a lot of ideas and I want these ideas to help the club to get bigger in reach and members. Since I’ve been at the club, we’ve set up a website which I currently run; we’ve redesigned the logo; signed up for most social networks; introduced new payment and donation methods to the club like JustTextGiving and just wait and see what I get done in the next 12 months. But it’s important that I explain the background and benefits of these new tools and systems to the other members. Most are used to using computers on a daily basis but if you’re not using them, the terminology used with these new tools may be confusing. I keep this in mind when trying to give a balanced but informative view on all new tech tools I suggest to the club.

Becoming More Diplomatic

Most of the club meetings are in person and a lot of the females in this group are Alphas. Being one of the youngest (and knowing that I like things done quickly), I’ve tried to be conscious of hearing and listening to the views of others. Ensuring I don’t cut people off when they’re speaking (a bad habit I have when I get excited, passionate or carried away) is something that I’ve definitely recognised and improved upon over the years. This helps me and the other members so everyone feels heard and that I’m generally being respectful.

Long Term Benefits For Me And The Charity Members

Developing your soft skills without an environment is difficult because you have no goal to reach or place practice.

Recognising that LVC is a good place to improve my soft skills means that when I’m around these women, I make a conscious decision to improve. Soon enough, I’ll have done this so often that these changes will be unconscious behaviours and hopefully make me a better person.

Identifying environments or events in your life that can help you to build upon your soft skills is something that I encourage you to do.

Make your journey towards self improvement easier, by giving back.

This post was exported in one click from Google Docs into WordPress with Wordable.

The Different Roles Within the Field of QA and Testing

Here’s my next post which appeared first on Simple Programmer..

This piece was a collaboration written by Kayleigh Oliver and Daniel Sayer, writer of the Unexpected QA blog.

There are so many job titles which cover the generic role of someone who works as a tester or someone within quality assurance (QA). Is it all recruiter babble? Does it denote the same roles and responsibilities?

Or are there significant differences in what a person will be expected to undertake determined by these job titles?

Here, Kayleigh and Dan will discuss the various current job titles for non-specialists they have encountered in their respective careers and work to define the high-level responsibilities of each title.

More specifically, they will describe the role of a tester or someone working in QA and put forward their explanations of what each title means, so you can formulate your own definitions and decide which would be best for you to pursue.

QA Engineer

Dan: The first thing to do when analyzing the job title is to break it down into its constituent parts, with QA short for quality assurance. I believe these parts convey the idea that the person occupying the QA role needs to focus on more than just testing. They should be the advocates of quality in their team, promoting others to increase the levels of quality in the work they undertake, the processes they follow, and the code they write.
The “engineer” portion in the context of quality assurance denotes more involvement in the release process for both defining and ensuring features, and changes are released with minimal negative impact to the end user.

Essentially, if we were to draw a Venn diagram of all quality/testing job titles, I would see “QA engineer” being slap bang in the middle, accounting for a little bit of every segment: testing, coding, process improvement, and championing.

Kayleigh: I agree with Dan about the QA part of this job title; any role with “QA” denotes that the person will be an advocate of the quality of the product.

The end user isn’t usually involved within development, so it’s the QA’s role to champion their objectives for that end user and to help improve the processes used during development to ensure a high-quality product is delivered.
But when I see the word “engineer” in a job title, I don’t think about the release process. This signifies that the role requires someone with technical skills. After all, the word “engineer” is rooted in the ability for that person to be able to construct, build, and develop something.

QA Developer

Dan: This is an interesting one. I would argue––and I’m probably going to cause some controversy here––that this role is made up. Linguistically, it doesn’t make sense to both test and develop (with testing being a large proportion of the QA responsibility to the team).
One of the reasons companies employ QAs as a separate entity from developers is to ensure functionality checking is done by a fresh pair of eyes. This is the same reason why QAs should employ techniques used by developers when writing code, such as code reviews. Some companies do not have QA as a separate unit and expect developers to test their own work; however, they aren’t called “QA developers.”

Therefore, if we take the perspective that the primary goal of any QA is to ensure the quality of the end product, it doesn’t feel feasible for someone to be a QA developer.

However, if you flip this on its head and try to envisage what someone would do if hired into a role with this title, I would imagine they would spend more time working on tools that enhance QA and be less involved in the production of features and changes to the main product. Why then not just have the title of developer?

Kayleigh: I disagree here. Not all developers are involved in the development of production code. Some just maintain the code and write tests, but they are developers and their focus is what’s important. They are expected to write code that contributes to the development of features and continual improvement of those features within a readable, extendable, and maintainable codebase. A QA developer would focus on writing code that contributes to the development of tests for features within a readable, extendable, and maintainable codebase.

To me, this role would have someone with technical skills that (as Dan so rightly suggested) could be working with other teams like DevOps or solo, building testing tools to aid QA and testers during their day-to-day work.

This role could also be another way to refer to automation engineers. These are typically testers that spend the majority (if not all) of their time creating automation scripts that run on builds to detect defects before the project reaches production. Developers develop, but QA developers would have a particular focus on quality and how they can improve the quality of the product.

QA Tester

Dan: When I see the word “tester,” I immediately think about the manual process of pushing buttons and clicking through websites. This title denotes that the occupant focuses more on testing as a manual task but is still involved in shaping the overall quality of the processes in getting changes or features released (denoted by the QA section of the title).

The role of QA tester isn’t one I have seen that regularly, with my focus being in public services, online gambling, and web and app services. Usually, employers either want the tester to have a direct influence on the product from the start of the process or only test it once it’s completed.

Kayleigh: I agree that the role of a QA tester is to perform manual testing. Again, this role requires the tester to be an advocate of quality from the end user’s perspective and to champion change to improve the processes that build the product.

Historically, you’d find that testers working within the games industry would perform only manual testing, so they were called “QA testers.” However, more industries are recognizing the importance of releasing a high-quality product and how a low-quality product can affect their reputation, brand, and finances. Even the games industry has started employing QA engineers and automation engineers. This distinction in titles makes me more confident that this role is purely manual.

QA Analyst

Kayleigh: I think this is quite similar to the QA tester. However, I think the QA analyst would be more involved in the development cycle during the user acceptance testing (UAT) stages.

Dan: I agree that there are definite similarities to the role of QA tester; both roles have their main focus on manual testing. I was once told that the difference between a QA analyst and QA engineer was that the engineer was in charge of the release process whereas the analyst’s focus was up until the point of release. I’m sure there’s more to it than this anecdote, if we put this job title under the microscope. It has similarities to a business analyst and, potentially, crosses over in roles and responsibilities such as UAT stages, as Kayleigh mentioned.

Automation Engineer

Kayleigh: This is probably one of the most well-known job titles on this list so far. The role of automation engineer is to develop (hence the engineer part of the job title) automation scripts to test production code.

The types of tests written will largely depend on the company you work for. Automation engineers tend to write integration tests and UI tests.

Usually, automation engineers are more likely to write UI tests since they test the application from the end user’s perspective. But depending on the company and its size, this role could write anything from low-level unit tests to high-level UI tests.

Dan: Again, I very much agree with you. “Automation engineer” is pretty much the Ronsil™ of job titles (does what it says on the tin). These guys (or girls) write automation tests, and that’s pretty much all they do. However, I don’t wish to belittle the task. With such a wide range of ways to contribute to automating the testing process, from unit to UI, there’s enough work to do to deserve a person specializing in this position.

Having been in a position where I was expected to write automation tests, these scripts need to be kept on top of. The slightest change or new feature can render all your tests obsolete, which is why strategies such as Page Object Model were devised; however, someone does have to implement this.

Software Tester

Dan: My thoughts on the role of a software tester are that it’s similar to that of a QA tester: mainly manual testing, focusing on the product and not on the process. It feels very much like a position where the work involves testing the product, and it either meets the expected criteria or it doesn’t.

My understanding may be swayed by the types of candidates I interviewed who came from a software tester background, but it did feel as if there was a perceptual difference between software tester and QA engineer.

Kayleigh: I would mostly agree again with Dan here. The software tester would focus on testing the functionality of the product to ensure it meets its intended use, but not test it from the perspective of whether it fulfills its business need. The word “software” is a generic catch-all that dictates you are a tester of digital products and not mechanical, like a lab or electrical tester.

Test Engineer

Dan: I believe the lack of specifying “software” in the job title identifies that the product under test could be hardware. However, I feel that this is where the differences cease. There doesn’t seem to be a hardware tester job title that’s employed with much frequency, so this is used for manual testers for hardware.

Kayleigh: Again, I’m disagreeing. Whenever a job title includes the word “engineer,” it implies a level of technical ability for that role. But other than that, I would agree this role focuses more on testing the product’s functionality rather than the business value it adds or the end user’s perspective.

Test Analyst

Dan: Test analyst is more of a Waterfall development process job title. Test analysts can either identify the targets from testing activities and enact the tasks to achieve these targets, or they can work in a more advisory position, assisting with preparation of test cycles, helping users during acceptance tests, and producing reports and analysis of the outcomes.

Kayleigh: This would be one role that suggests you’re going to solely be doing manual work. However, this role would focus more on testing from an end user’s perspective rather than merely ensuring the features are functionally performing.

Software Development Engineer in Test (SDET)

Kayleigh: This title was first used in 2005 by Microsoft. This title is the most technical for someone in the testing field because their role is to both develop and test, often across different stages of development. The person undertaking this role may develop many different types of tests, for example integration, contract acceptance, and UI.

To be able to perform all of these types of tests, you need to have an understanding of what makes a good test, the types of testing required at each level, and how to implement them.

Giving this type of technical tester a title with the word “development” means the candidate should have a greater technical ability. It also makes the title easier to understand to those outside of any development role. Anyone can guess what a software developer does, but you need to also explain the role of an automation engineer. This is the role that I believe is the closest to an SDET.

Dan: As you said, Kayleigh, this role has been around for a while now. An SDET is a developer that focuses on testing. SDETs are highly proficient in coding and development practices but do not get involved in the development side and remain focused on ensuring the product is in a testable position.

I feel the perception is that SDETs would rather code a script than manually execute a test, regardless of the time and effort it would take. I am aware of several places that would utilize SDETs to refactor code to make it more testable. This isn’t the norm but does go to show the wide skill set those employed in this position need to have. But how is this role different from that of automation engineer? I believe it’s the same job under a different name and cannot see a noticeable dissimilarity between responsibilities. However, if I was in this position, I would rather be known as a software development engineer in test. It has a nice ring to it, don’t you think?

Do Job Titles Really Matter?

Ultimately, a job title can give you only so much information into what you will be doing. Many jobs will be posted by non-QAs (recruiters, development managers, etc.) that even if there was a consensus on the titles above, there would still be so many nuances that you have to look at the job description to make an informed decision. You’ll find some uniquely named positions after a quick search on popular job sites, such as Test Ninja, which shows that our list and discussion isn’t exhaustive.

We both agree that the description of the role is more important than the title, as it’ll convey the detail and day-to-day actions of the role. However, job titles are still used to denote the level of authority of an individual at a glance, so it does matter what title you are working under.

What to do if Your Job Title Isn’t for You

Again, it’s true that a job posting may be different from what you actually undertake in the role. You may find that your role is different than the title you originally applied for.

If you’re not happy with your current title, we would suggest you speak to your manager and negotiate a title change in your next performance review. Remember to go with evidence of the additional tasks you undertake so you can justify a title that more represents your day-to-day workload.

If you’re not happy with the extra responsibilities you’ve undertaken which don’t usually fall under this role, we suggest you also talk to your manager. Maybe these extra tasks are pulling you away from doing your best work and spreading yourself too thin. Whatever you may be unhappy with, come to a compromise with your manager; don’t just carry on.