SillyCon Valley

Dust off that ping pong table!

2022 is right around the corner. Clichés aside, there are some widely known and validated Universal truths about how staying healthy physically, emotionally and mentally has an impact on your dev team’s coding skills. As a CTO, you could perhaps encourage your team to just make getting healthier a New Year’s resolution that will fade away into oblivion within a month. Instead, entice them to take action. Albeit on little things – and no, beer jug lifting does not count – like taking breaks. Breathing deep. Getting up and walking around. Reading a little or taking a nap. They will feel better and, often solutions to problems appear when thinking of something else albeit for a little while during the workday. They may not know what the bug is they’re looking for, but they may know test cases and prints to isolate it!

Genes and serious pre-existing conditions aside, anyone, regardless of occupation, who is not overweight, does not smoke, drinks minimal or, preferably, no alcohol, eats healthily and in particular eats minimal junk food, minimal sugar or additives and only the recommended amount of salt is likely to be giving themselves a very good chance of staying healthy. Raising the computer, having an external keyboard and stretching periodically can help and are recommended but are not nearly as important as the other factors mentioned. At the end of the day (or the year), you’ll see that not only only your team feels great, but their code will no doubt glow. 

Do you foster healthy habits amongst your team?

WE CARE ABOUT YOUR TEAM’S WELLBEING!

‘Tis the season?

All right, your team has been hammering away for months on end on that awesome software product, app or update. Predictably, they will all want to launch it ASAP so that the world drools in awe. Right? Well, seems like it might not be such a good idea. It might be a tax on your team to release before a weekend or a long vacation. It’s also not fair to your customers, because what if something goes wrong and there is no one to fix it?

Of course you test everything before releasing it, but that doesn’t ever mean that it will be 100% when it gets into the wild. Instead,  you might want to release products and updates during low user counts and at a time that you can have everyone ready if something goes wrong. More people will be available to fix problems should they arise. Besides, good developers constantly think about their work. If they dream up an edge case during a smorgasbord of honey baked turkey over the Christmas weekend, there will still be Monday and Tuesday to coordinate a response.

Also, particularly during the holidays, planning a release right before the weekend or a holiday might be frowned upon. Your team will know exactly what that means. Instead, you might want to plan a release when you expect the maximum clients, social app should be launched before the holidays while business apps would be launched when the maximum staff attendance at work is expected upon returning from the holiday season.

If you are planning to launch soon, have you given some thought to the pros and cons of doing it before, on or after the holidays? What do you think the best approach would be? 

LET US HELP YOU LAUNCH RIGHT!

No, you’re not a party pooper. You are just drained.

Don’t be fooled. Software developers have an extremely demanding job, often without praise, only finger-pointed at when bugs are found. And even the more collaborative development environments are still very work/problem-centric.

While problem solving brings great enjoyment, personal internal “problems”, which are not analytical by nature, become extremely frustrating and can have a devastating impact in the software developer’s mental and emotional well-being that won’t just go away with back-patting and cheering from well-meaning peers and colleagues. Yes, close connections absolutely helps, but doesn’t always lead to the comfort needed.

A trained mental health care professional or emotional therapist who you can trust is the best bet. If you are interested in a support group, there are options which do not need to be tied to your profession or your peers in any way. The support provided by those who share similar struggles transcends professional alignment. Also check out online sources like Techcrunch’s article on ‘5 Ways to Improve Mental Health for Software Developers‘, and those on social media platforms and other mental health forums where people with similar challenges converge. It’s an awesome step just to reach out like this. Be proud of that.

Holidays or not, what actions are you taking towards making sure that your software development team’s mental and emotional health remains optimal?

CONTACT US TO LEARN WHAT WE’RE DOING!

Keeping the flies at bay

This is what GIGO stands for, and it can make a dent on almost every aspect of Life, but it applies particularly well in coding. In software engineering, GIGO is just an acronym that is usually used to stress the importance of sanitizing and validating input, whether it be from the user, a data source, a remote source, or elsewhere.The point is that if bad data is input, it doesn’t matter how well the program is written or how perfect the algorithm is, the end result won’t be good. 

This is equally true of the algorithm or the implementation of the program, by the way. If the wrong algorithm is chosen, you are going to get the wrong results – that’s still garbage in. Similarly, you might have great data and the right algorithm, but if the implementation sucks, you’ve still got bad input. It’s still good old GIGO. 

Bottomline: if you input unintended, even nonsensical, data (“garbage in”) to a computer (operated by logical processes), then it will produce undesired, often nonsensical, output (“garbage out”). Have you ever seen this principle in action? What can be done to prevent its harmful effects on code? And – last but not least – what can be done to keep a swarm of filthy flies at bay? 

CALL US, WE CAN HELP YOU FIGURE IT OUT!

If you are easily disturbed by pure technical gore, don’t read this.

But if you’re not… read on! When it comes to software outsourcing, not everything is milk and honey. It’s only fair to highlight some grim facts, too. Horror stories do happen. Particularly if things like language barriers, communication styles cultural fit are factored out to add to the coding challenges themselves. CTOs or VPs of Engineering that need to add software developers at a “low rate” sometimes fall into the trap of not even checking in the code to make sure it works, either because of an excess of trust… or just plain stupidity.

Probably the biggest mistake many companies – SaaS, software product or even brick and mortar that need devs – make is to treat the offshore team as “the others”, or “them”, instead of “us” and “we”. They would have never fallen prey of the the monster they themselves helped create in the first place, had integrated everybody as one, coherent, well-aligned team that can be trusted. Quality is a function of personal relationships within the team, the company, and even its customers.

What has your own experience in software development outsourcing been like? 

CALL US, WE CAN HELP!

Good, Great and Zen Developers

What makes a great software developer? One that writes good code, one that writes no code, or one who deletes code?Many CTOs, VPs of Engineering and VPs of Product will most likely align with the notion that good software developers are those who understand what makes users tick, even beyond the scoped requirements. Good devs know how to follow specs, code proactively, and are aware of the intricacies of the language or environment that they use. They abide by best practices to create robust, secure code and can explain and defend those practices. They are disciplined and play along as a team, even on something as mundane as code formatting or commenting standards even if this does not match their personal preferences.

Great devs are those who read reference manuals and the literature before embarking on futile quests to rediscover hot water. They are devs who know how to communicate effectively with their teammates and are not afraid of receiving well-meaning criticism or to respectfully offer it when the situation calls for it. Great devs take pride in the quality of their work and don’t hesitate to ask questions as needed. They are engineers who take ownership of problems and solve them instead of passing the buck.Some people say that good programmers write good code, great programmers write no code, and Zen programmers delete code.

What do you think the difference between good and great development is?

CALL US, WE’LL HELP YOU BUILD THE PERFECT TEAM

Shooing recruiters away

To reel in great software engineering talent, you recruiting team needs to spend time  looking only for truly compelling resumes. These not only narrate the work and education story of the devs but also allows them to know that candidates have the necessary skills, education and experience to perform a good – even outstanding – job.

You will most likely want your applicants to stay away from resume points that only show what they were assigned to do and what they did in the role – usually referred to as ‘grunt’. This is not a good description of how they spent their time in any past professional scenario. Instead, look for impact statements that focus on what was accomplished, what the outcome was and what impact they made, like “developed X to accomplish Y, resulting in Z”.

Should you look – or worse, ask – for a pic on a resume? Not really (in LATAM, you’d be surprised how many recruiters and HR managers make this mistake) Look for links to their GitHub, StackOverflow, or LinkedIn profiles, each of which may or may not have a profile picture.

Is your recruiting team being shooed away – and wasting time – thanks in part to an influx of poorly crafted resumes? If such is the case, let us help you find out what works best for you. 

CONTACT US, WE CAN HELP!

Sometimes, we just don’t function.

As a CTO, you probably know that functions are a good alternative to having repeating blocks of code in a program while also increasing the reusability of code. Values can be passed to a function using variables called parameters or arguments. They can also return values and do many other nice, cool things with software that’ll make you look good, even if your devs didn’t have coffee that day.

But we’re all human after all, aren’t we? Sometimes even the highest coveted software engineers might simply have had a bad day at home and not call their functions. Should this be the case, if you want to reduce a complicated program into smaller, more manageable chunks and avoid unnecessary complexity in a program to ease your day (and your output)…have your dev team remember to create – and call – their functions.

But just in case…make sure they are wearing spandex pants or stretch jeans.

And if your development team could use some overhaul to function properly…

CALL US NOW TO FIND OUT HOW WE CAN HELP

Not all specs are stitched together, like Frankenstein’s monster. 

The most commonly known best practices in software development determine that a document that describes what the software will do and how it will be expected to perform is created as a first step. It also describes the functionality the product needs to fulfill the needs of the user. This being said, have you found yourself in a position where you throw a bunch of specs at a developer, simply hoping that the outcome does indeed fulfill the expected needs and functionalities, only to be deceived? If the outcome was less than satisfactory, was it because of the specs themselves, the development team’s quirks, sheer bad luck or an act of God?

We’d love the chance to help you find out!

CALL US NOW TO FIND OUT HOW WE CAN HELP

To comment, or not to comment. That is the geeky question.

Commenting involves placing human readable descriptions inside of computer programs detailing what the code is doing. Some developers are convinced that proper use of commenting can make code maintenance much easier, as well as helping make finding bugs faster… But is that always the case? Some geeky devs believe that well-documented code is as important as correctly working code.