DEV Community: Alan Hylands

What Should I Do When My Data Science Project Gets Canned?

Alan Hylands — Mon, 11 Nov 2019 13:29:55 +0000

This article first appeared on SimpleAnalytical.com, a blog for data analysts looking to grow their data skills and level up their data careers.

All that work down the tubes.

So your data science project that you worked on for six months got canned and you don’t know what to do. There are two distinct phases to recovering from such a mortal blow:

Anger comes first.

Gnash your teeth. Weep. Loudly. And in a sobbing fashion. Lie on the ground and kick your feet like a toddler in a supermarket that has been told to put the packet of sweeties back on the shelf.

Acceptance and personal growth.

Pick yourself up off the ground. Dust yourself down. Put on your Big Person Pants and get right back in the game. Because tomorrow is another day.

But why did your project get binned when you worked so hard on it?

The odds were against you from the start. A recent article in Venturebeat says that 87% of all data science projects never get put into production. You don’t have to be a mathematician to work out that in reality that means about 1 in every 10 DS projects gets green-lighted while the rest get flushed. Not exactly encouraging when you frame it like that, is it?

So what stops the rest making it beyond the Proof of Concept phase?

Crappy Model.

Sometimes your model just plain sucks. Sorry, them’s just cold hard facts. Maybe the data scientists involved just weren’t experienced (or good) enough to get the most out of the data they had in front of them.

Could be there was a lack of business knowledge amongst the DS team that made them ask the wrong question. It happens. Again, inexperience or not collaborating with the right subject matter experts at the project scoping stage means you've basically wasted your time. Wave it goodbye.

Crappy Data.

Or the data they had to stitch together into a Frankenstein’s Monster-style creation from disparate spreadsheets, handwritten notes and whispered conversations under bathroom stalls wasn’t quite good enough to wring anything meaningful back out of it.

I should have “You Work With What You’ve Got” tattooed on my arm after the amount of times I’ve used it to account for less than desirable data situations over the years.

Frightened Management.

It’s one of life’s mockeries that the businesses with most money available to spend on data science teams are inevitably the ones who have the most risk-averse senior management with the most stringent regulators breathing down their necks. Think banking, insurance and healthcare for obvious examples.

All rotten with money and all (quite rightfully) shit scared of the heavy hand of regulatory authority coming down on them. In the choice between drawing a line through your project or getting hauled in front of a regulatory panel, there’s only ever going to be one winner. Sorry champ.

Shiny New Object Chasing Management.

A particular favourite of mine. They follow the trends in business magazines just long enough to kick projects off when the buzzwords are hot but not long enough to see them through to a proper conclusion.

Brought in to staff a Big Data team in Hadoop last year? Sorry pal, budget removed. We’re all doing AI this season, hadn’t you heard?

Office Politics.

“Why did Jane get budget for her project and I didn’t get any for mine?” “Why did Tom get ten more staff and I had a headcount revision?” etc. etc. The average corporate boardroom has more to offer David Attenborough in terms of animalistic territory marking behaviour than the Amazon rainforest.

Back-stabbing. Talking behind backs. Power struggles. Coups. Counter-coups. It makes Game of Thrones look like a quiet family sitcom. With the inevitable result that someone wins their Game and someone loses. And looks like this time it was your project. Them’s the breaks kid.

Communication Breakdown.

This happens a few levels down from the boardroom bickering Cold War-esque shenanigans we just covered. This is shop floor, inter-department, inter-team rivalry and it’s just as cut-throat as the war the suits upstairs get into. Data Engineering don’t talk to Data Science. Data Science don’t talk to Data Management. Data Management don’t talk to Business Intelligence.

And no-one talks to I.T. because they are a bunch of basement dwelling neckbeards with no standards of personal hygiene or inter-personal skills. Or so you heard Steve from Data Engineering say in the queue for coffee in the canteen.

Either way, we need a well oiled machine working in unison. Instead we’ve got a bunch of unicyclists all off doing their own thing with no co-operation towards the bigger picture. Is it any wonder that even projects that get into production don’t end up delivering any of the benefits they initially promised? Hell no.

What can we do to increase our project’s chance of success?

Winning the rollover lottery jackpot has a probability per ticket somewhere in the tens of millions to one. But still people buy them. If our chance of data science project “success” is around 13% then why wouldn’t we try to increase our chances of being on that side of the equation?

Looking at the reasons for failure above, we see a few we can’t quite control at the operational level. Execs gonna exec until the cows come home so we’ll ignore that one. Hoping we’ve not got one of those business magazine, hype-chasing senior managers is another one for the wishlist but hard to control in real-life.

Instead try these three points to increase your project’s chance of making it to the holy land of production deployment:

Pick the right problem.

Banging your head off a brick wall form the get-go won’t get you anywhere. You have to be realistic about what you are trying to do and how it will ultimately be implemented by the business. If it’s a long shot right at the start, it’ll make it a lot harder to keep bouncing it over the inevitable hurdles you’ll face to get it live further down the road.

Start small, stay simple.

Ensuring you don’t over-complicate the problem (just because you CAN doesn’t necessarily mean you SHOULD) is the main slogan to stick over your workstation. Simple doesn’t mean basic. It means easier to explain, easier to sell to your management and their management and easier to implement. There are no prizes for taking the hardest road possible just to prove how smart you are. It’s a self defeating policy right out of the blocks. Don’t do it.

Get the right team together to tackle the problem at hand.

Teamwork makes the dream work. Uuggh, I feel dirty even typing that. But it’s true. Office politics and inter-team rivalries will always exist but try and work through them for the greater good. It would amaze absolutely no-one who has ever worked in a corporate environment that the biggest obstacles to success are to be found within your own organization. The "competition" don’t even come into it. Work to overcome that in your project and you’ll have a much higher chance of success.

And it’ll still probably not make the grade.

I don’t want to put a downer on your mood but the odds will still be against you. A 1 in 10 strike rate should be expected in an experimental area like data science where not every idea is going to survive the Proof of Concept stage.

I'm seeing more and more despondency from young analysts and data scientists though when their long-term projects get shit-canned for whatever reason. I've been there myself and it's one of the major learning experiences, even further on in our data careers, that not everything is going to go into production. It's not called Data "Science" for nothing.

Educating the bosses.

Another major problem seems to be a misunderstanding at the executive level that every project should be a winner or else the whole discipline is a waste of time. Which ultimately boils down to a lack of basic data literacy at senior levels. This is key to the success of any data-driven strategy and is often overlooked.

As modern data professionals, we need to figure out how to educate our business leaders and bring them along with us as data equals. If we don’t we’ll see more and more projects fail and the attention will turn elsewhere for the next magic bullet for business success. And that would be a missed opportunity for all of us: nerds, suits and pen-pushers alike.

If you enjoyed this article join my mailing list for weekly(ish) stories, hints, tips and interviews from across the data world.

(Photos by Paweł Czerwiński and Raychan on Unsplash)

10 Ways To Get Active In The Data Community

Alan Hylands — Thu, 12 Sep 2019 13:21:11 +0000

This article first appeared on SimpleAnalytical.com, a blog for data analysts looking to grow their data skills and level up their data careers. If you enjoyed this article join my mailing list for weekly(ish) stories, hints, tips and interviews from across the data world.

Remote working has been one of the major highlights of the technology revolution of the past decade.

Taking the dog for a mid-day walk. Picking your kids up from school. Hitting the gym at lunchtime for a serious biceps session (what, just me?)

Can’t do those sitting in an open plan office with 200 other people trying (and failing) to focus on their SQL code.

But it comes with downsides too.

Working from your low cost of living, no commute, small town means you are miles away from a major city and the in-person tech communities that live there.

It can get lonely. You can feel like you’re being left behind and working in a virtual vacuum.

This can be tough at any stage of your career but especially in the formative early years when it’s even more important to soak up knowledge from co-workers a little further down the track.

Even if you live and work in the city, you might find your rather introverted nature is bringing up anxiety on getting involved with other data professionals outside of your own day-to-day work. So how do we overcome these issues and get more active in the data community?

10 Ways To Get Active In The Data Community.

Here are 10 ways for you to get up and running and find your data tribe. Online or offline, we have plenty of options to experiment with:

1. Get involved in online forums.

Doesn’t matter where in the world you live, fire up your browser and you’re instantly in a massively crowded room full of people looking for the same thing you are - to be part of a data community.

My personal favourite online forum is Reddit. It gets a bad rep sometimes because of it's vast size and the breadth of topics it covers across hundreds of sub-Reddits. Don’t let that put you off.

When it comes to data, I stick to a few well-moderated and (largely) friendly subs, /r/businessintelligence, /r/datascience and /r/dataanalysis.

You can niche down further depending on your own tastes with forums specifically for SQL, Python, PowerBI, Tableau - you name it, Reddit has a large crowd of people ready and willing to talk about all aspects of it.

But to get the most out of your online data community forum experience, don’t limit yourself to just reading the other posts. That’s a great place to start and feel your way into the internal culture of how other forum members talk to each other.

But to really get into the community, you need to chip in on discussions. Add your own take on what’s being discussed, even if you think someone else has already said it. There is always real value in bringing your own experience to the table.

2. Twitter.

I’ve found the data community on Twitter to be the most welcoming, helpful and (generally) least toxic of all the social networks. Find the right people to start following and then go down the rabbit hole of seeing who interacts with them and who you want to keep up to date with.

There is so much excellent content being shared it can be difficult to keep up so try not to get swamped. As with forums, you’ll get more value out of overcoming the fear of joining in by actually tweeting replies and adding your own take on discussions.

It’s a community so there will be the odd knob. Block and mute are your friends. To paraphrase Van Wilder Party Liaison, arguing on the internet is like a rocking chair. It gives you something to do but it doesn’t get you anywhere.

3. Facebook Groups.

I have major trust issues with Facebook as an organisation. But it’s hard to argue with the number of specialised communities that it houses in Facebook Groups. Whether you are into Power BI, Tableau, different cloud providers, data science, data analysis, you name it, there will be a ton of Groups sitting waiting to receive you.

That doesn’t mean that all are created equally though so it will take some trial and error to find ones that suit you. The more controlled nature of FB Groups in terms of sheer volume of members means it can be easier to get your voice heard but you do have the downside of less regular discussions coming up from the smaller pot of people. Maybe that suits you better than a wide open space like Twitter or Reddit though.

4. LinkedIn.

It’s the number one business-related social network on the planet. There is a vibrant (and talkative) data community discussing all manner of data-related topics on a daily basis.

Everyone who is anyone is on there including all major recruiters for top companies all over the world. But sometimes the feeling that it’s all a bunch of sleazy salesmen selling to other sleazy salesmen can be hard to shift.

I read my LinkedIn news feed some days and feel like I need to have a bath. And then a shower just to make sure. It makes me feel dirty. Saying that, there are some great data folks on there providing daily valuable content.

The comment sections can be hit-and-miss. It’s easy to get lost in the throng of self-promoting big talkers who are always eager to push their gatekeeping agendas. But get the right people to follow and you can learn a lot.

5. Write your own blog and newsletter.

Once you’ve got your sea legs with commenting on Reddit and Twitter, you’ll find the comment and Tweet format aren’t quite enough for all you have to say on a subject. That’s the time to start your own blog.

Even if you are posting articles to the sound of silence for a while until you build up a readership, it’s still the most valuable development programme you can put yourself through.

Own your platform. Self-host using Wordpress or a static site generator (like Gatsby, Hugo or Jekyll) and just get writing. It improves your process of thinking through problems and is a great way to show potential employers that you can 1) write and 2) deliver those thoughts in a clear and succinct manner.

Get enough people reading your posts and start a regular email newsletter list as well. This is hands-down the best advice I can give to any data professional. Bar none.

6. Post articles on Dev.to and Medium.

When you’ve written your articles then you can cross-post them for further distribution on content aggregators like Dev.to and Medium.

I prefer Dev myself as the community here is smaller and a little more cosy than in other places. Don’t just drive-by post and then run off. Get involved the comments on yours and other posts and become a proper part of the community.

That’s what it’s all about after all. Offering up your own articles and thoughts is just your table stakes. The real value comes after that by helping others and joining in discussions on what they have to say about what you have to say.

Medium is bigger but they have a paywall and I don’t think it improves the service for readers or writers. Plenty of data people disagree so it’s purely a matter of personal taste.

7. Local meetups.

“Just a small town girl living in a lonely world”.

Journey had it right but it doesn’t have to stay that way for you in your hometown forever. If you have a large town or small city nearby, look on meetup.com for any data-related local meetups, make the effort to visit and meet some real human flesh people.

If you don’t find any then start your own. Even if it’s a handful of people from your town sitting around one small table in a coffee shop, it’s a start. And you might be surprised how many others like you are out there just waiting for something to materialise.

If you are on the introvert end of the scale (like me), you might even be better off organising your own as it gives you a job to do and something to focus on rather than sitting like a non-speaking extra at the side of the room. Just a thought.

Following local data community people on Twitter might give you an insight into where and when they go to meetups and a quick DM can be a great icebreaker.

8. Conferences.

The souped up version of local meetups. Hundreds (maybe thousands) of people milling around. Salespeople on booths trying to grab your interest. Too many talks to see in a day. And ticket prices that can run into thousands.

None of these are selling points to me. I don’t like big crowds for a start. Conferences can be incredibly useful though if you take a strategic plan of action to them.

Get your company to pay for it. Always.
Have a very targeted pre-plan for which talks you want to see. Don’t just wing it on the day, it rarely works out well.
If there are other people you’ve been in contact with on social media or forums (you have been interacting haven’t you?) then pre-arrange to meet up with them for a coffee in-person if it suits them and they have time.

Probably best not to wander around until you spot them and leap out from behind a booth to tell them you’re their number one fan. Personal boundaries and all that.

No-one wants to be friends with Annie Wilkes no matter how much they enjoy their ego being stroked.

9. Sign up for data newsletters.

The good thing is there has never been so much fantastic free data and analytics content available on the internet. The bad thing is...there has never been so much free data and analytics content available on the internet.

How to sift through it all to separate the wheat from the chaff? You can’t read or listen to everything or else there would be no time to do the actual analysing. So signing up to some of the data community leaders’ newsletters is a good start.

Some like Avinash Kaushik’s Occam’s Razor are excellent as learning pieces in and of themselves. Others are a great way to get curated links to interesting content from a wide range of sources, some you may never have seen or heard of on your travels.

Interacting with those running the newsletters can be as simple as replying to their email, most are more than happy to discuss what they’ve been sending out. Plus you can also use those articles you have been writing for your own blog and pitch them as potential content for the newsletter in future.

Win-win scenario for all involved.

10. Build and launch a data product.

There are two simple steps to generating some interest around yourself and the things you are doing in the data community:

1) Make something.

2) Tell people about it.

Doesn’t get much simpler than that (in theory at least). But what do you build that hasn’t been done before?

For starters, who said it never had to be done before? Get a data source, could be open data or even scraped from the web. Transform it, display it and put it somewhere people can see it. Job done.

Could be an interactive dashboard. A niche job board scraped from various other sites. Or convert a spreadsheet with some measures about different cities for travellers into a fully fledged public-facing product like Pieter Levels did with Nomad List. I don’t think Pieter classes himself as any kind of data scientist but that doesn’t matter.

Data is the glue that holds together all areas of business. Ideas are all around you.

And once you’ve built v1.0, get back onto your blog to write about it. Then tell people in the forums and social media groups that you’ve been befriending and see if it starts any new conversations. And who knows where that might lead for you?

Now it's over to you.

I hope these have given you some ideas for how to move out of your comfort zone in getting further involved in the data community. There are so many options available, both on our doorsteps and across the globe, but they’ll only become valuable if you make the effort to join in and contribute.

Creation, not just mindless consumption, is the key and that advice crosses over to more facets of our lives than just data. Good luck in your adventures!

If you have any other suggestions for ways to get involved in the data community or experiences you want to share, please get involved in the comments.

(Photo by Perry Grone on Unsplash)

Five Hard Earned Tips For Increasing Your Wordpress Security

Alan Hylands — Wed, 19 Jun 2019 20:08:37 +0000

Old Friends.

Wordpress and I have been both friends and foes for going on fifteen years now. We've had our ups and downs during that time. But at some point I think we decided it was better to focus on the good we've done together rather than the struggles that were driving us apart. In that way, we're very much the Mick Jagger and Keith Richards of my online publishing life.

I've done the full monty when it comes to using Wordpress. Blogs galore. E-commerce sites with Woocommerce. Membership portal and booking platform. Affiliate sites fed from every kind of datastream. You name it, I've done it with Wordpress.

A New Client Site.

The latest client site I did was an appointment booking and management site for a sports massage therapist. The site build was smooth, the client incredibly helpful and enthusiastic. When we launched to the public, there were plenty of great quotes and testimonials about how easy it was to register and use. And then the fun began.

The hackers started almost immediately. I noticed some dodgy looking users signing up and caught a backdoor takeover attempt just at the vital moment. This was not what I planned when I took on building this system. Who wants to play whack-a-mole every day as every script kiddie all over the world tries to take over your client's site?

Answer: nobody.

So I doubled down on my usual security measures and put together this list of 5 top tips for helping increase your Wordpress site's security.

Five Top Tips For Increasing Your Wordpress Security.

1) Do Your Updates

This is my #1 for ensuring no-one takes advantage of your lackadaisical approach to Wordpress security. If you can, set Wordpress to auto-update the main core install when a new version is available. If you've been sensible and spare with your use of plug-ins and don't have too much custom development on the site, it should cure more ills than it creates. (Keep regular backups just in case though).

Don't forget to regularly check and update your plug-ins for updated versions as well. It's a warzone out there and if you don't keep up to date (sometimes on a daily basis) there is a queue of assholes out there just itching to take advantage of your vulnerability. Don't give them (or their bot armies) the satisfaction.

2) Install Security Plug-ins

But didn't you just say don't go mad with the plug-ins? Make your mind up.

Wordpress can be clunky enough with a basic install, never mind once you go mad and start installing dozens of plug-ins that you then have to maintain and keep up-to-date. I would advise an exception when it comes to the matter of security plug-ins. I've adopted the belt and braces approach on this score and am currently employing the services of Wordfence and iThemes Security.

Both have their strong points and given the concerted attacks I've been facing I figured it was better to take the full benefit of both. Wordfence has an excellent file scanner function while iThemes Security has a multitude of different options to alter the "normal" Wordpress configuration. Both plug-ins have Premium options which will help bulk up your security even further. Got a Wordpress site that's providing the basis for your entire business? The investment is an absolute no-brainer.

3) Enforce Strong Passwords

I know it's easier to remember a simple one word password that you've used for every website log-in since you got your first computer. I know it's tempting to allow your users to do the same but, in the words of Celine Dion, think twice. Plug-ins are available which specifically allow you to set your password policies and there are often options in other log-in related plug-ins to bulk up your password complexity rules. Use them. Always.

If you've installed one of the security plug-ins above you'll find options there to enforce strong password rules as well. Belt and braces as I said. Go draconian and save yourself some serious pain in future. To make remembering 20 character random passwords easier I've recently started using 1Password. It took a little getting used to after slumming it with the Google Chrome Password Manager before but I'm glad I made the switch now.

4) Disable xmlrpc.php

Ever heard of this legacy throwback to a simpler Wordpress age? Probably not unless you sat and picked through your Wordpress install file by file. It basically allows remote access to your site which was more useful back in the good old days and has almost been completely deprecated in modern versions of Wordpress. I found it was being hit like mad from IP addresses all over the world one evening as hackers tried to access the administrator account on my site.

(I'd wisely decided to not just call the main admin username "admin" which is another good WP security tip.)

If you have no need for it, you can disable the xmlrpc.php file with a dedicated plug-in (wouldn't be my first choice - see above for reasons), with code in your .htaccess file or - my choice - through another setting on the iThemes Security plug-in.

Time will tell if it makes a major difference but the suspicious activity in trying to hit that file from proxied IPs from Montreal, Finland, Italy, France and more within a few minutes was enough to make me draw quick line through it.

5) Don't Allow Users To Self Register

This won't always be an option depending on the nature of your site. If it's a free-to-sign-up members portal then it's not really on the cards. I'd been lulled into a false sense of security (pardon the pun) over the years when I'd been able to shutdown registration for users on blogs or let the site managers handle adding new users manually.

This time I needed Joe Public to be able to register and book appointments themselves so it was time to tighten up the old constraints and limit them as much as possible.

Limiting Dashboard access, enforcing strong passwords (there it is again) and keeping an eagle eye on just who is signing up for your site are absolute necessities if you can't stop them registering themselves. For even tighter controls, you could use Captcha (and have EVERYONE hate you) or make users click a confirmation link in an email to confirm they are who they say they are. Neither are foolproof but then what in life really is?

Is all of this security effort worth it?

The bottom line and my main takeaway is really combine as many security measures as you can without clunking your site up to the point where it becomes absolutely unuseable. Anyone who has been in charge of a website of any description, not just a Wordpress install, will know that you just can't trust people online to play nice.

Whether it's posting disgusting material on their Facebook page, harassing people with hateful comments and messages or just being a plain old pain in the ass on a forum, the internet really seems to bring the worst out in some people.

And that's before you get to the site hackers we're trying to stop. Some do it just for the hell of it. Some because they can. And some actually have a gameplan behind it more than just defacing or infiltrating someone else's space. Do all you can to not let them win and destroy all of your hard work.

The clean-up can be excruciating and is a horrendous waste of time, money and anxiety and prevention is ALWAYS better than cure. Good luck.

This article first appeared on AlanHylands.com where I write about a variety of topics including business, personal finance, tech, careers, writing and my quest to build a simple kind of life.

Migrating My Blog From Wordpress To Gatsby - Part 2

Alan Hylands — Mon, 27 May 2019 13:22:13 +0000

I wrote in Part One about finally biting the bullet and giving Gatsby a go. Having dipped my toe in it's delectable waters I knew full well that it was only a matter of time before I went deeper down the rabbit hole.

So I spent the past couple of weeks converting my main data and analytics site Simple Analytical to Gatsby from Wordpress. Yes, there is an element of yak shaving in there.

Falling out of love with Wordpress.

Wordpress is a fine CMS and so it should be - around 30% of the entire internet runs on it. That doesn't mean that it's without fault and the longer I used it for that site, the more it started to irk me.

To be fair, not all of these were the fault of the Wordpress eco-system, in fact, probably few of them were. But anyone who has done anything with Wordpress over the past five years will tell you how it's virtually unrecognisable from the chippy young go-getter it was back in it's early days.

I had a few major issues:

1) SECURITY.

My reseller hosting package kept falling over due to mod_security rules getting flagged. Not sure whether it's fair to strictly blame WP for this. When a long established hosting company tells you that they'll have to switch the security rules off altogether or you won't be able to edit any of your existing posts then you know something is amiss with your software.

Wordpress is notorious for it's inability to maintain adequate security levels at the best of times. Any Wordpress admin who says they haven't ever been hacked just hasn't been in the game long enough. It's almost an inevitability and a rite of passage.

I was updating plug-ins EVERY day. And I mean EVERY day. It's great that the developers were patching things quickly and regularly but when it turns into a tedious daily job monitoring and making sure the updates happen, it's time to re-evaluate your approach.

When, as I said above, the host tells you that the only eay to let you edit posts is to switch more security off, it sends alarm bells ringing. LOUD ONES.

2) SO MANY PLUG-INS.

The great thing about the Wordpress eco-system is the sheer number of plug-ins. One of the worst things about the Wordpress eco-system is the sheer number of plug-ins. By the time I'd had enough with the daily updates, I was running 18 different plug-ins on my WP install for Simple Analytical.

No-one made me use them all but I'll swear blind that none of them were extraneous. When you get to the point where you have to install yet another plug-in to shut down the use of the new Gutenberg editor that you didn't want in the first place, it's time to re-evaluate your choices in life. You'll notice I was getting to the re-evaluation point quite a lot here.

3) SPEED OR LACK THEREOF.

Tomorrow we will run faster.

The main reason behind me moving Simple Analytical to Gatsby can be summed up in the quote above. Simply put, building my blog site with Gatsby and hosting on Netlify lets it go like the proverbial shit off a shovel. For the non-Northern Irish amongst you, that means it's rather quick. Like greased lightning kind of quick. Usain Bolt quick.

Testing on localhost is never a fair representation of what it will be like in the wild but even there it was looking DAMN good. Getting it going on Github and Netlify didn't lose any of that speed and I couldn't be happier.

Simple Analytical is a blog. It's a collection of articles giving my perspective on issues, trials and tribulations data analysts find at all stages of their data careers. It's text and a few images on the screen. That's it. It doesn't need a full database and CMS behind it. Gatsby let me get back to that and I'm very grateful.

So how did I approach the migration?

I'd learnt a lot from my first foray into the world of Gatsby (note: you're reading it now). One major difference with porting over my analytics blog was that people actually read it...

I wanted a few things that I didn't have with this particular starter:

a top navigation bar.
categories to split up the main types of content (e.g. Articles / Interviews)
tags for further classification with the articles or types of interviews.
Mailchimp form integration.

Where to begin the search?

I didn't want to code the whole site from scratch. My React and Gatsby powers aren't quite there just yet. But I did want something I could hit the ground running with and lose none of my existing content.

After a lot of trial and error with different starter sites from the excellent Gatsby Starter Library I still wasn't getting what I wanted. I turned instead to the Gatsby Showcase to see how some of the top Gatsby sites on the web had been put together. The Showcase has over 500 Gatsby sites on display, many of which have made their source code available on Github.

A little help from a kind stranger.

The manu.ninja site caught my eye. It's the personal blog of front-end developer Manuel Wieser and had all of the basics nailed for what I wanted for Simple Analytical. Clean, straightforward design and layout. Blog. Top nav bar. Provision for other content pages, tags and categories.

So I downloaded Manu's source code from Github and got to work. After a lot of tinkering, hacking, slicing, dicing and creating, I had whipped Manu's original into something a little more my own. Couldn't have done it without all of the original hard work being made available for use on Github though which is an amazing act of generosity to help further the community and learning of other developers. Thank you Manu Wieser!

Old world meets new world.

Porting over my own content from the Wordpress site was a time-sink but a necessary evil. Peter Akkies had written an excellent blog post on exporting your Wordpress posts to Gatsby markdown which pointed me in the direction of the Wordpress-to-Hugo exporter plug-in.

This plug-in saved a lot of copy-pasta and hand converting and maintained frontmatter as well. I did still have to manually review all of the posts (circa 60 posts and pages) and manually correct any markdown that didn't translate properly. Peter does warn in his article about having to fix slugs and some frontmatter to fit the Gatsby blog and GraphQL so it wasn't a surprise. If I'd had hundreds of blog posts to convert it might have been a different story. As it was I did a little scripting to speed up some naming changes etc. as I tried a few different starter set-ups so having some Python or other scripting language up your sleeve is useful.

You've Got Mail(chimp).

The biggest addition to the manu.ninja code I had to bring in was Mailchimp form integration. I went for the gatsby-plugin-mailchimp plug-in and configured a general email sign-up form to include after all posts on the Simple Analytical site.

I will have to re-visit this in time as it only sets people up to be added to the generic newsletter mailing list. If/when I add specific content upgrades and mini courses back into the site I'll have to find a way to include those tags back into Mailchimp. There is always more dev to be done.

Any other issues?

I mentioned in Wordpress->Gatsby part 1 that I'd had to do an email workaround and I've done the same thing on this site migration. Netlify DNS is very easy to configure so adding A and MX records to point to the mailserver at my other hosting provider was pretty simple.

Otherwise, the migration was quick. The site is VERY fast on pageload and Google's Pagespeed Insights tool LOVES it.

I'll report back in future if any major problems show up but for now I'm more than happy to have made the switch. I'm not finished with Wordpress. In fact I've spent a good part of the week putting a booking system together for a client using Wordpress and the excellent Amelia plug-in.

I'm not planning on becoming a full-time front-end dev either but it's been an interesting sojourn into this world. Javascript and web apps have came on a long way from my early days using it. But the support and guidance from so many devs in the community through blog posts, articles and forum answers has been a big help into getting up and running quickly. I'm looking forward to building on the basis of these two sites I've migrated over to Gatsby. And who knows, I might even get around to writing more articles for them along the way!

Migrating My Blog From Wordpress To Gatsby - Part 1

Alan Hylands — Sat, 18 May 2019 11:26:02 +0000

Where it began.

Language wars and chasing shiny new frameworks have been a hallmark of the web development world for as along as I can remember. My first website was hand-coded in HTML in Notepad. We're talking late 2001/early 2002 here.

I opened up Internet Explorer and there it was in all it's glory. It was a simpler time.

I jumped over first to Microsoft Frontpage (clunky and horrible) and then Macromedia Dreamweaver which was a LOT smoother to use. And somewhere along the line I stopped hand coding HTML.

By the time I started my first blog in 2005 there was a new kid on the block that everyone seemed to be talking about - Wordpress. It's hard to believe now but back then there was still a lot of scepticism about Matt's ability to really make a dent in the CMS world. Especially at a time when PHP was already starting to draw it's fair share of criticism from the developer community. Looking back now as around a third of all websites run on Wordpress, you have to say Matt knew what he was doing!

Over the intervening years I put a lot of time into building websites with Wordpress. Woocommerce shops. Affiliate stores with product pages populated from Amazon's API (amongst others). Salon booking systems. Membership sites. Personal blogs over and over and over. Grand opening, grand closing. When I wanted to build a website I installed Wordpress. Me and most of the rest of the world as the number of WP installs shows.

Back in the saddle again.

Early last year I started blogging and writing again more seriously than I had done in the best part of ten years. I'd been busy building a corporate data science career. And a family. Not necessarily in that order but certainly concurrently. I wanted to write and share some of what I'd learned during that period. Being involved in businesses, large and small, and finding the sweet spot where tech and data started to make real business improvements, I thought I had something worth writing about.

So I created SimpleAnalytical.com for my data science writing and AlanHylands.com for all of my other many varied writing interests. Wordpress for one. Wordpress for the other. And for a while it worked well. Like a comfortable old pair of trousers, my old friend had stretched a little but was still just about recognisable enough for me to jump back in with a vengeance.

Where did it start to go wrong?

Wordpress is well stocked with a world of plug-ins for any and every eventuality a site developer might need. The same goes for themes as the web creaks under the weight of so many Wordpress free and premium theme offerings. My tastes are rather simple as you can tell. Even so, in a serious case of yak shaving I managed to rack up just under 200 versions of the home page design for AlanHylands.com. Yes, 200. And in the end the last version I had as a bastardised version of the Generatepress theme was this:

200 versions and I got a plain white homepage with a picture and a little text. Job well done. Ahem.

The site was still slow however. I didn't use a lot of fancy wizardry but the number of plug-ins still seemed to mount up. Google's Page Speed Insights app didn't like it at all. It ran like a dog. And seeing as all I was doing was writing an occasional article with a lot of text and a few images I got to thinking - why do I need all of these plug-ins and a database at all?

I've been getting well into the community at the excellent Dev.to and I started reading more and more about static site generators. Hugo, Jekyll, Gatsby. The names kept coming and I was intrigued. I hadn't written any Javascript in a LONG time so the thought of having to learn all of that to even get started was enough to put me off.

I needn't have worried though.

So I bit the bullet and decided to give Gatsby a go. I'd been reading great things about Netlify as a host and with a little over a dozen blog posts to convert to Markdown I figured I'd convert AH.com and see how I got on. Worst case scenario it would be a few hours wasted but if it turned out well...

Standing on the shoulders of giants.

React developer Dave Ceddia has an excellent beginner's guide to starting a blog with Gatsby and Netlify which was perfect for what I needed. Getting my hands dirty with the terminal, Node, Javascript and Github was a great introduction to this whole world of frontend development that has happened while my gaze was somewhere a little more data-sciencey.

Dave walks you through installing a Gatsby starter to get up and running quickly. Once I'd poked around at it and made a few changes I got my confidence up and started moving the blog post list to another page and re-creating the look of my previous Wordpress homepage in Gatsby.

New posts are written in Markdown and are essentially text files so it's incredibly lightweight and there is no need for a database. There is no admin section or scripts to hack so it's more secure that way as well. Everyone who has ever ran a Wordpress website knows how easy it is to drop the security ball. Especially when we start adding more and more plug-ins to get added functionality. SSGs don't have quite the same issues which is a great bonus. They are also lightning fast which readers LOVE (and so does Google). Double bubble.

Dave's tutorial walks you through pushing your new blog to a Github repo and then deploying it to Netlify. It takes a matter of minutes and it's live. Boom. Job done. Well, not quite.

A minor fly in the ointment.

Things are never quite as stress-free as we would like when we aren't working from a green field site. For me the main issue was the email address I use for quite a few log-ins and communications. Netlify doesn't do email hosting so I had to scramble around and piece together a solution from around 20 open Chrome tabs and searches.

I'm still testing it out just to make sure it's worked ok but I think I've found a workable solution. My old reseller hosting package uses WHM and cPanel. Using my existing account on there I was able to add A and MX records at Netlify DNS to re-direct any email back to the email host on my old account.

There I can set up email forwarders and use their SMTP for sending under an alias through my personal Gmail. If it looks like being a success longer term I'll write that up as it was a bit of a sweat to work out.

What's next?

I've still got several updates to this site that I'd like to do so it'lll remain a work in progress. It's clean. It's fast. It's something new for me to play with and a good base to explore more about Gatsby. But I don't have a navigation bar at the top and I think I'll add that next. Anything to avoid doing any proper work!

What I really have to think about now is whether I want to migrate Simple Analytical over to Gatsby with a lot more posts, code blocks, tables and Mailchimp integrations. Watch out for Part 2 when I get that conundrum worked out.

So am I done with Wordpress now?

Simple answer is no. Like all tech options, it will come down to horses for courses. For a clean, simple blog I like the thought of just writing up a Markdown file, uploading it and seeing it live. For sites and online apps that could be doing with the full Wordpress admin backend and database, I'll still look to it for the foreseeable future.

Life does not have to be a case of EITHER/OR, sometimes it's good to keep a few options in your toolbox. I've made a career out of being a Data MacGyver, no reason to change that when it comes to the end of nearly my second decade building websites as well.

(Originally posted on AlanHylands.com)

How To Build Your Data Science Career Change Action Plan

Alan Hylands — Mon, 08 Apr 2019 10:13:28 +0000

Your Job's A Joke. You're Broke. Your Love Life's DOA.

You've spent the last ten years grinding it out at a job that you don't exactly swoon over when the alarm clock goes off. It's starting to feel like life is passing you by and you know there must be something out there that you can really get your teeth into. But which direction do you go in to find it?

So you read some articles online about Data Science being the sexiest new career path since the last sexiest new career path. And it starts to sound interesting. Who wouldn't want to find out more and see if this whole data world could open up for them?

I'll be honest now. Coming into the data field at age 30 or above without any prior experience or tech background can be tricky. To short-circuit the whole "how do I even get started?" problem I always suggest planning backwards.

What is Backwards Planning?

Backwards Planning is a great concept I learned from Amy Hoy and Alex Hillman from stackingthebricks.com. Essentially it means looking at what you want to get to as an end product (e.g. writing a book, building a data product...hooking a data analyst job) and working back from there. What does the end result look like? What’s essential and what’s nice to have? What do I need to prepare up front? What has to come first? Etc. etc. All questions to take you backwards from your end goal to where you are now so you can fill in the blanks in between. (You can read more about using Backwards Planning in Amy and Alex’s book Just Fucking Ship).

When it comes to approaching a career change you need to look at getting that new data analyst job as your ultimate end goal. If you know your end goal then you can plan backwards to find the steps you need to take between there and now to get you to that place.

These five steps in fact.

The 5 Step Guide To Backwards Planning Your Career Change.

1) RESEARCH YOUR TARGETS

Go to a jobs site like Linkedin or Indeed and search for "junior data analyst" jobs in your hometown. Go through the wordy job descriptions and make notes on what they are asking for. Pay particular attention to the technical skills, education and soft skills sections.

When you've got enough data together, you can start to pick out the actual skills and requirements that will get you in the door at more of these jobs. Got those skills already? Great, you’re one step ahead. If not then it’s time to work out how to get them.

2) TECHNICAL SKILLS

I'll go out on a limb here but you will probably see Excel and SQL pop up most often in Required Skills. These are the fundamentals of working in a BI or analytical role in the vast majority of companies, both large and small. If you don't have these skills then you know where to start your learning. You don't have to be the world's best Excel jockey or SQL superstar either. You'd be surprised how many people get tripped up at the first hurdle on these entry requirements. Make sure that isn't you.

Excel and SQL really are two givens in terms of necessary knowledge in the broadest range of companies so it makes sense to pick those off first. At this level there's no sense in spending a fortune on training when you have the likes of Udemy courses available for under 20 dollars. Have a look on there, check out the class ratings and reviews and jump on in. I’m a big believer in getting the Pareto Principle and making sure you get the basics right. If you can nail 80% of the most important SQL commands or Excel functions you’ll be streets ahead of the entry level competition. Even those graduates from fancy colleges. In fact ESPECIALLY those graduates from fancy colleges.

You can get into a coding language like Python or R afterwards. Having a curiosity to dig into datasets, thinking of questions and then finding the answers from the data is far more important than listing 20 different programming languages at this stage of a career change. Those of us who scan CVs and resumes when hiring analysts can tell immediately that you are a bullshit artist if you rhyme off a shopping list of programming languages and database technologies. Especially if you are straight out of university. Better to know the important ones well.

3) EDUCATION

Do you need a 2 year college course or bootcamp in Analytics to learn Excel and SQL? No. Not at all. Despite that, not having even a bachelor's degree will tend to be a barrier to getting in the door of many organisations. I don't agree that they SHOULD require it. I've worked with plenty of excellent folks who don't have them and it hasn't stopped them being damn fine analysts but HR departments often disagree. If you don't have one, search out the jobs that don't ask for it and see what they want instead. Or just apply anyway. Let them weed you out if they want but don't rule yourself out unnecessarily.

In fact, that’s probably the most important piece of advice I can give for your job search. Companies employ masses of HR people who are only fit to scan for buzzwords on application forms. If they have a strict policy like only hiring graduates for entry level analyst jobs or only hiring from top level colleges then it’s their loss. Angela Bassa is the Director of Data Science at iRobot. She covered this very subject in a Tweet thread about how she wouldn't have passed the Master's or higher graduate-level degree bar herself on a team that SHE set up. And she went to MIT! It's a ridiculous example of artificial gatekeeping. But in a crowded job market it happens.

Some companies are a little more forward thinking however. They give their recruiting managers a little more leeway when it comes to who they bring in for an interview. As more people change careers in their 30s, 40s and 50s than ever before, it makes sense to not rule out picking up a diamond that may have otherwise been discarded. Don’t limit yourself by deciding you aren’t fit to apply. That’s someone else’s job, not yours. Fortune favours the brave. If that’s you then the next step will be where you can really shine.

4) SOFT SKILLS.

Let’s say you've worked as a chef. If there is a more highly stressful, on-demand, pressurised working environment I've yet to see it. You should have learned plenty of skills running your kitchen that can transfer over to a BI analyst role. See what the job listings ask for (e.g. "Ability to be self-managed, work independently as well as to collaborate within an agile, fast-paced, dynamic team environment.").

Ever worked with other people? Have you worked on something on your own? Been under pressure on the job? How did you deal with it? Was there something broken in the process you were meant to follow? How did you fix it?

These are the kind of open ended questions that really show how you will deal with situations in the real world. It's not all about the technical chops especially for folks with some previous life experience in other arenas. You mightn’t be able to quote the exact dictionary definition of what a SQL window function is but if you can show me you know how to Google things, I’ll respect that more.

Prepare some examples of when you have displayed these soft skills in your career and life to date. Don't be afraid to use non-work related examples either. I've had people use their experience in sports clubs or other organisations to display their soft skills at interview. I'm always happy to explore those as it shows they can transfer the skills beyond just the office work environment.

(I should say that I hate the connotations of these highly valuable skills being termed “soft skills”. It’s as if they are an afterthought or not quite as useful as the (presumably) “hard” technical skills of programming and working with databases. Anyone who has ever had to manage a team of other grown-up human beings will know this is horse shit.)

5) SHOW US WHAT YOU GOT.

When you've built up your skills a little, it's time to show people what you can do. Write blog posts documenting how you approached a project. There is a common misconception that seeing as everything in the world has already been written about then there is no point you doing the same thing. That’s bullshit. Write about what you have learned regardless of how basic you think it is. Get used to communicating your process and what you’ve found. HINT: these are REALLY important skills to have as a professional data analyst.

Or get a dataset, analyze it and present what you've found. (Just don’t use pie charts. Please). Interested in sports? You'll find plenty of sports data online, jump right in. Got a book on your coffee table full of the US Government’s notes on Italian-American gangsters of the mid-20th century? Source the data, cleanse it, wrangle it and analyze it (just like a project I’m currently in the middle of writing up).

For your online portfolio, Google and read as much as you can from other data science folks who have posted theirs online. Unfortunately a lot of us aren't able to discuss actual projects we've done on the job due to NDAs etc. but there are still a lot of great resources out there to pick over. See what the format is like. How did their voice come over in the writing? How did they present it? Github/Jupyter Notebook/R Markdown? It’s all research, all analysis. Even the searching and researching is building your data skills. Learn from everyone, pick the best elements and plunder all you can to learn more.

The Final Pep Talk.

It might look like a lot of work but this is a great field to get into. Career progression through the many different areas of data science is good and well compensated. Getting a foot in the door is the hard part but it's well worth it and there is no better time to start than today.

Overall, I'd say just work hard on picking up just enough new skills to be able to demonstrate you can use them. Don't want until you consider yourself an expert to get applying for jobs. The real learning, as in any field, is done on the job as you are adapting to real world situations. And, in the immortal words of The Carpenters, on that front “we’ve only just begun…”

..........................................................

If you enjoyed this article you should sign up for my weekly newsletter at SimpleAnalytical.com. You’ll get advance notice of new articles, along with a veritable treasure trove of added data-related bonuses. Cheatsheets. Ebooks. Code samples. And more.

Fewer Dashboards, More Analysis

Alan Hylands — Thu, 21 Mar 2019 17:07:37 +0000

It pains me to say it but Business Intelligence has gotten itself a bad rep. And we're all partly to blame.

It’s pretty clear that to most people in the data science world, BI means building endless reports and dashboards - and that’s all it’s good for.

Take a look around your own workplace. I don’t care if it’s a bootstrapped start-up or a global corporate giant. Odds are that the virus-like spread of the BI dashboard has reached epidemic levels. BI teams are stretched thin building more dashboards than the Tesla factory. And the requests just keep growing.

The business teams are demanding more and more and more. “I need a new sales report”, “I need another traffic report”, “I need another hundred metrics on this dashboard or else it’s useless and I can’t run my business and it’s all your fault and...and….and….”

Someone please wake me when the nightmare is over.

WE. NEED. TO STOP. FEEDING. THE. DASHBOARD. ADDICTION.

It’s not that I’m against providing valuable insight to management based on the data we have at our disposal. Quite the opposite.

I’ve spent most of my working life trying to deliver better insights through data-driven projects. I might get jaded at times when it feels like I’m banging my head against the metaphorical (and sometimes physical) brick wall. But I’m not suggesting we throw the baby out with the bathwater.

Gut feel (or what should more correctly be termed Subject Matter Expertise and Experience) alone doesn’t work either. We need a joined up approach that brings the two worlds together.

I want everyone to slow down on the “drive to dashboards”. Endless reports filled with countless metrics are not the best way to get full value out of either your data OR your data team.

Benn Stancil, the Chief Analyst at Mode, wrote an excellent article called Don’t Choose Dashboards Over Analysis. Benn says:

“Though it sounds counter-intuitive, more dashboards often make people less informed and less aligned...a company with hundreds of dashboards can’t focus on anything.”

And he’s dead right.

I see some dashboards so jam-packed with metrics it’s difficult to even work out what they contain, never mind what they are telling us. The "More Data/More Dashboards" game-plan really only provides a comfort blanket for indecisive managers. They really want an inanimate object to blame if they make a decision that doesn’t quite pan out.

It’s a symptom of poor company culture that a scapegoat and sacrificial lamb have to be prepared well in advance of any business choices happening. But that is often the choice junior and middle management have put in front of them. They carry all of the risk but little of the responsibility to really move the dial. So it’s easier to sit and play spreadsheet games with the moving numbers on the BI dashboard instead.

How does incessant dashboard building impact the data team?

My philosophy is that data analysts should be analysing data. Not blindly building more and more reports. It’s our job to analyse and, most importantly, interpret what is happening in the business. Spotting trends and investigating the causes and possible drivers is where the real value is gleaned from having a strong data analyst team.

If all you have them doing is building mega-dashboards which mash up and squeeze in hundreds of different figures, you’re wasting their time. Every second is vital and the opportunity cost of that time sink is the inability to get focused thinking time to properly analyse the real data at their disposal.

What gets measured, gets managed.

But does it really? Basecamp CEO Jason Fried spoke about his views on this oft quoted business mantra when he appeared on Tim Ferriss’s podcast (episode 329). Jason suggested measuring less. He tests by removing elements of what he does measure then sees if it makes any difference to their business performance.

It clearly hasn’t had a negative impact on Basecamp’s success over the years so maybe Jason is really on to something.

I advise business people to really focus on no more than five key metrics if they really do have to measure their KPIs. I mentioned a senior exec in another article who was only interested in one key metric. At her level that was all of the management info she needed to see how her division was working. I balked at the time when I heard the story but understand it better now.

Less is more. It’s OK to not look at everything all of the time lest we get snowblind, as Benn Stancil suggests in the quote above.

I’ve seen this from both sides.

I’ve been a data analyst for many years. And I've worked very closely with business stakeholders to try and understand exactly what they think they will get from their latest round of MI report requests.

Conversely I’ve ran businesses where it’s easy to get caught up obsessing over small details. There is always the anxiety that you’re missing something important if you aren’t proactively measuring EVERYTHING, every second of the day.

Real-time reporting feels like complete control but it comes at a price. You gain a close-up view but lose the big picture.

There has to be a trade-off.

As an analytics manager, it’s your job to talk the business side down from the idea that they NEED to see everything all at once and all on the one page. They don’t. They need to focus on what really moves the dial for their area of the business.

As an analyst, you need the space and time to dig into the data and ask it better questions. You're wasting everyone’s time if you're on a constant treadmill to deliver more reports that will rarely get looked at. And no-one needs that realisation.

If you're in the business owner’s chair you need to take a deep breath and take the advice I give when working as your data consultant. Focus. Don’t spread your attention too thin. And use the data to lead you to a place where it’s telling you a story, not just showing you more and more numbers on a screen.

Getting to that stage needs the ever useful help of the data detectives in your analyst team. But you’ll never know if you keep them tied up on those dashboards and comfort blankets all week instead. Free them. Utilise them. Or you will inevitably lose the best of them.

The choice is yours.

Q&A with Helen Anderson, BI Data Analyst and Technical Consultant

Alan Hylands — Thu, 28 Feb 2019 13:11:32 +0000

This interview in the Simple Analytical Analysts Assemble series is with New Zealand-based BI Data Analyst and Technical Consultant, Helen Anderson. I first ran into Helen while she was writing an excellent series on SQL here on Dev.to.

I've since found her to be one of the most helpful and approachable members of the site and a great proponent of helping encourage everyone in the community. I'm very pleased to say she's agreed to share her story and data journey with us here.

Over to Helen...

1) Tell us a bit about yourself, how did you get into the data space and what does your data journey look like so far?

Hello! I’m Helen Anderson and I’m a Data Analyst and Technical Consultant on Xero’s Data Services team. I support Xero’s Analyst Community with code review, building datasets they need, maintaining the database they use for their work and providing guidance for junior analysts.

My data journey so far hasn’t been the most traditional one.

I didn’t study computer science or even IT at university. After graduating with a Business degree I landed in the world of Supply Chain Analysis. I really enjoyed solving the puzzle of how to get the right stuff to the right people at the right time. Putting together a plan based on the customer's needs, the shipping timetables and in the case of my first job shipping apples from New Zealand around the world, what the growers estimated they would harvest. Even though we did everything using Excel it set me on the path to where I am now.

Since then I’ve worked for the Royal NZ Ballet working on revenue projections based on theatre seating configurations, Timex in London planning manufacturing of watches for Europe and Icebreaker balancing stock between locations around the world.

Making the move from working in Excel to coding in SQL happened when I joined Xero three years ago. I started in the Marketing team as an analyst pulling lists for email campaigns and doing post-campaign analysis. I was pretty late to the game when it came to using SQL, but was hooked. Now I am working in the BI team in a role that allows me to support those junior and not so technical analysts, who were ‘me’ three years ago while growing my technical skills working on projects to build data models a new database platform.

2) What’s a typical day look like for you in your current data role? (Which tools and languages do you use? Big team/small team/lone wolf? Office-based or remote?)

For the first time in my career, I’m on a big team of analysts, developers and engineers. There are almost 30 on the Data Services team. A big difference from being the lone analyst in most of my roles so far.

When I first joined the team the imposter syndrome hit me pretty hard.

When you are the lone analyst you do what you know because there’s no one but StackOverflow to ask. I’ve spun those feelings around and made a point of asking for help and learning from those around me with many years of experience. We have an incredible team culture, everyone is happy to help and we celebrate success with a monthly Awesome Award to celebrate everyone’s good work.

We have a team of analysts who work on ad-hoc data requests, a BI team that build models that are used in reporting, a Data Engineering team that maintain the data pipelines and platforms and MicroStrategy consultants who make sure the self-service visualisation platform is user-friendly.

Because my role is to support Analysts in teams across the business I get to do a little bit of everything. Some days I’m building a custom data set in Redshift to support analysts work, showing them how to use Microstrategy to present their reports or troubleshooting the Airflow jobs that move data to the dedicated Aurora database we maintain to support their work.

3) You've built up a large following through your blogging. How important do you think it is for data professionals, at all stages of their career, to share publicly what they are doing and learning?

I began blogging on my self-hosted Wordpress site the last time I was on the job hunt. To no surprise, it wasn’t exactly flooded with new visitors.

After seeing a colleague blogging on Medium, I weighed up my options and decided to take the plunge on Dev.to. I’m really glad I did. I’m not a traditional web developer or software engineer like a lot of the community, but I still have something to offer.

My first few posts were ‘listicles’, easy to read, but felt a little too Buzzfeedy. I reassessed the tone and found a more conversational voice. The same way I’d talk to a colleague about a technical subject, but without recreating technical documentation.

Blogging is beneficial in so many ways.

You're reinforcing your learning or understanding of your chosen technology or tool. So even if you only get a handful of views, you have still done something worthwhile.

This is all about your unique point of view. Which doesn't mean you have to know everything on a topic. That's why you are writing a blog post, and not rewriting technical documentation.

Even if you are beginner explaining how you are learning how to use a new tool, your perspective is important. You never know who may stumble across your post and find your explanation of a topic helps it all click into place for them.

4) Where do you see your own data career going next? Building on your technical skills as an Individual Contributor or moving into a more management-based role?

I’m incredibly lucky to be on a team that encourages both. Right now I’m building up my knowledge of the quirks of PostgreSQL, as that’s the flavour of Aurora database the analysts I support have moved to. I’m working on gaining more of an understanding of the data pipelines that load the data in and the AWS services we use to build the infrastructure for my own interest and to get to know more about what our DevOps and Data Engineers do.

I’m looking forward to supporting the junior analysts more as the analyst community grows and will be giving public speaking a go with my first tech talk really soon. Even though I’m not making the career change to Management I’m still able to support and teach those around me.

5) If you had a list of “best-kept-secrets” (websites, books, coaches), which would you recommend?

I put together a list of resources I think are great for Junior Analysts recently that cover not only the technical side with SQL but the human side too - requirements gathering, visualisation and communication.

My favourites blogs at the moment are:

Data36 - https://data36.com/ for tutorials and hands-on learning.

Simple Analytical - https://simpleanalytical.com/ for commentary on being in the data world and the ups and downs of being an analyst.

Mode - https://mode.com/blog/ - content for analysts by analysts.

Soft Skills Engineering - https://softskills.audio/ - my favourite podcast advice show about non-technical topics.

6) What is the number one piece of advice you give to aspiring data scientists?

Being a great data analyst or scientist is more than just churning out SQL and knowing your way around the database. It's important to learn how to listen to stakeholders and determine what it is they need from a report or dashboard. Put equal amounts of effort into learning communication skills, interpreting the story behind the numbers and presenting data in a way your end user finds the most digestible.

By honing these skills, as well as building models and your technical skills, you’ll go far.

7) Where can readers find you online?

You can find me blogging regularly on Dev.to, on Twitter, on LinkedIn or my own personal site.

If you liked this interview with Helen, please keep an eye on SimpleAnalytical.com for more installments in the Analysts Assemble series. If you work with data, in your job or spare time, and would like to join the series, please drop me an email: alan AT simpleanalytical DOT com

Is SQL Really A Game Changer For Data Science Careers?

Alan Hylands — Mon, 11 Feb 2019 10:12:48 +0000

I’ll nail my colours to the mast right away on this one.

SQL is the most fundamental skill you MUST have to get started in a career in data analysis. We can argue it out until we are blue in the face over whether R is better than Python. Or whether SAS and Java are dead. Or Spark is more useful than Azure. None of that matters unless you have the lowest hanging fruit plucked and safely placed in your skills basket.

And that is SQL.

Some relevant statistical research.

Data Scientist Jeff Hale carried out an excellent piece of analysis recently on the most in-demand skills for data scientists. He wrote it up for KD Nuggets and it’s well worth a read for both aspiring and current data analysts.

Jeff scraped job postings on LinkedIn, Indeed, Monster, SimplyHired and AngelList to see which terms were showing up most regularly for various data science related job vacancies. He searched only within the United States and did exact match searches on the terms: “data scientist” “[keyword]”.

The most interesting part for me was the rankings he put together for various technology skills. It will come as little surprise to anyone who has scanned data science job vacancies in the past 6-12 months that Python, R and SQL came in 1st, 2nd and 3rd respectively.

But didn't you say SQL was most important?

You might think I’ve shot my own argument in the foot here by using a piece of research that shows SQL as only coming in third in the list. If over 70% of listings wanted Python skills and over 60% specified knowledge of R, shouldn’t we concentrate on those first? I don’t think you should. And here’s why.

SQL is easier to pick up the basics from a standing start. Even if you only learn some basic uses of the SELECT statement you will already be ahead of 99% of Excel jockeys who never bothered to move beyond copy/paste and VLOOKUPs.
SQL crosses all areas of the wider data science world. Want to be an analyst? Learn SQL to SELECT the data you need from the data warehouse. Want to be a data scientist and run machine learning? Use SQL to clean up your data before getting into algorithms. Fancy building data pipelines as a data engineer? SQL. SQL. SQL. SQL.
RDBMS databases are here to stay. There will always be a shiny new object in the database world to distract us. (I’m looking at you MongoDB.) But the vast majority of companies and online applications still run on the big three of MySQL, SQL Server and PostgreSQL. You don’t have to have worked with them to notice something jumping out of their names at you. Hint: it’s three letters long and rhymes with prequel.

There’s another element to SQL coming in third in Jeff’s analysis though and it was brought up by Kristin Kehrer in her analysis of Jeff’s analysis. (Yes I know, it’s like turtles all the way down with analysts analysing each other’s work.)

How important is SQL?

Kristin asked how important is SQL and was surprised to find it only came in 3rd. She believes that may be explained because hiring companies see SQL as being so fundamental as to be a prerequisite when hiring data scientists.

I would wholeheartedly agree. When hiring data analysts I immediately discard the CV in front of me if they haven’t demonstrated SQL knowledge. It’s not even a question of it being desirable. It’s a necessity right out of the gate.

I was lucky enough when I fell into the data world as I came from a web and software development background. I’d been building desktop and online applications in healthcare and e-commerce and a fundamental part of that was being my own development DBA.

Not only designing and developing table structures, I was writing and optimizing queries and stored procedures in both development and production stages. Small teams need full stack skills and knowing SQL was one of the top ones I relied on: day in, day out.

SQL is a superpower.

When I first started as a data analyst in my current workplace, I just picked up where I’d left off writing SQL as a developer. The other analysts on my team looked at me as if I was some kind of witch when I was writing sub-queries and hand-coding SQL. They were still using the drag n' drop query designer in Microsoft Access. I didn’t know any different though and it helped me hit the ground running and make a big impact early on.

The case for the defence is almost ready to rest.

I see questions like this one asked regularly on internet forums and my answer always starts and ends the same. If you want a career in data analysis, you will be doing yourself a massive dis-service by not learning SQL. Keep building on that foundation throughout your career but please learn the basics.

SQL is the gift that keeps on giving.

You will not regret it. I promise.

Want more articles like this? Sign up for my newsletter on SimpleAnalytical.com for weekly(ish) stories, hints, tips and strategies from the real world of analytics.

Which fictional character best describes your job role?

Alan Hylands — Thu, 24 Jan 2019 15:13:23 +0000

We've had a few good posts on the old "What Is Your Job Title?" question here on Dev (here and here). But I have a problem with job titles. They invariably tell us nothing about what you actually do while sitting in the chair for 8+ hours each day.

I thought we could have a little fun with it and see if anyone can show which fictional character they feel best represents what they really do in their job. Could be from a book, a TV show, a movie, comics, songs, whatever - just as long as you can tell us which characteristics or actions tie them back to your role.

I'll go first.

My job title is "Head of Retail Commercial Excellence". (Gives very little away, doesn't it?) These days, my role is best described as a cross between Winston Wolfe from Pulp Fiction and Liam Neeson in Taken.

I use my "particular set of skills" to take care of difficult problems. Maybe not quite in the same way those two take care of their problems but still...data can get very messy.

Throw in a bit of Tom Hagen from The Godfather for mediating between different factions and areas in the business to deliver executive orders. And a dash of Obi Wan Kenobi after he became one with the Force as I help mentor and advise people in the mystic arts of our systems and business data. And you're 90% of the way there.

(Yes, I have given this question some thought!)

It's not just a bit of fun.

You never know who you might get chatting to at a meetup or online. Answering the inevitable "And what do you do?" with "I'm a <insert generic meaningless job title>" really won't do you full justice.

If someone told me they were a mix of The Wolf and Liam Neeson though I'd probably give them the old eye roll so don't necessarily rhyme that off. But at least get the main concepts of what it is you actually do beyond the usual generic "I write code"/"I analyse data"-style answers. You never know where the resulting conversation might take you.

I've ran analyst interviews where the candidate couldn't deviate at all from what they've (sparingly) written on the page. Sometimes it reads like it's been cribbed straight from the job advert that they got hired on the previous time. It never fills me with confidence that they might actually have the street smarts to operate without needing to be hand-held the whole time. And no-one wants that.

Now it's your turn.

Let's see what you've got for us.

Not Failures, Just Currently Uncompleted Projects

Alan Hylands — Fri, 18 Jan 2019 10:15:49 +0000

The Boneyard Of Unfinished Projects.

Overgrown, Unloved and Populated By Shame.

We've all been there. Haven't we?

I read a fine article about never finishing anything by Scottish writer and designer James Greig. The article, in turn, prompted a very good Hacker News comment page which really brought home the impact the associated feelings of shame have wrought on so many people.

(James Greig has a very readable blog with a lot of articles chronicling his difficulties with career burnout and depression amongst other things and is well worth a read, in and of itself.)

Where did it all go wrong?

This article about never finishing anything particularly resonated with me for obvious reasons.

Like most developers/designers/writers/creatives (delete as applicable), I could fill a skip with the number of started-but-not-finished projects I’ve accumulated or jettisoned over the years.

Websites without number, affiliate sites, content sites, e-commerce sites, this blog a number of times. Software projects like the football betting predictor (again several different iterations, none of them brought to market), plans for a football management game, the Cosa Nostra gangster game, the series of data science/analytics articles, the countless novels, the business style books, the book about England’s one cap football wonders.

Sometimes to look at the list of never-was, it seems like I never actually bothered my arse getting to the finish line on anything. Once the first flush of excitement was off on a project then it ultimately got consigned to the project graveyard. It might have taken an hour, a day, a week, a month, 6 months but ultimately it all wound up the same.

There is a distinct sense of impending doom that the perfection anxiety brings that leads to this. What if people laugh at me? What if they tell me it’s (read: I’m) no good? Mix in a healthy dose of imposter syndrome at any time and it’s a lethal cocktail.

Are we being too hard on ourselves?

One of the Hacker News comments about James’s article got it right though.

It’s better to frame these “failures” as being projects you haven’t finished yet rather than projects you didn’t finish. I know that I need to see small successes along the way and force myself to keep the momentum going. We just need to remind ourselves of that early enough on to not derail things when the going gets tough. And by tough I mean when the actual hard work of real creation begins.

There is an overriding fear of failure that I’ll cover more deeply at another time but it’s a self-fulfilling prophecy. The “project that never was” is no less of a failure than one poorly executed and ridiculed by peers. In fact it's more so.

Looking at the wins, not the perceived losses column

I have, of course, finished a great many projects.

I started State of the Game as a means of getting my football writing out into the world. It grew and grew, brought me into contact with a lot of interesting characters and got me the opportunity to write professionally for About.com and the New York Times Company.

I got back into e-commerce after a long time away to help grow Liz's Lockets. Simple Analytical has brought me into contact with a lot of really good analysts and data scientists already. We have to credit the wins, however small they may appear in the grand scheme.

Launching a very small, "inspired by Hello Dolly" Wordpress plugin may not seem like something worth shouting about. Physically chalking it up in my wins column this month made it worth writing a blog post about building my first Wordpress plugin. It builds confidence for moving on to bigger projects with more at stake.

Good things happen when we ship, even if the first version is a little rough around the edges. We all need some small wins to get us moving along the path to the bigger ones.

Finish that first draft even if you think it reads like a hot mess. It's not called the vomit draft for nothing. Get it out, start to polish it in the second draft and see how far it's come. This applies equally well to web and software projects as well as art or writing.

What changed?

I'm no spring chicken these days which is maybe why my attitude has changed so much recently. Forty approaches and while it's not old (well...), it's not young either. That old clock is always ticking.

More than that, I want something to look back on to show myself I didn't just sit and vegetate creatively through all of my "prime" years. Working the day job and building a career is great but I think we all need something more beyond that. Something you can show off without being tied into corporate NDAs for a start.

When push comes to shove, we all need to Just Fucking Ship as the inimitable Amy Hoy puts it.

I take a lot of motivation from Amy's attitude. You really should too.

(Originally posted on AlanHylands.com)

What Should I Do If My BI Project Gets Ignored?

Alan Hylands — Mon, 07 Jan 2019 15:36:19 +0000

Let’s see if you recognise this one.

You’ve spent weeks deep in the bowels of a BI request.

You’ve chased down the data sources, you’ve wrangled those mothers and made sure the ETL pipeline is flowing freely.

The midnight oil has been burned.

You've made sure everything is where it’s supposed to be and looking just like you wanted it to.

You’ve been:

dashboard building
perfecting the visualisations
and making sure the reports don't just display some numbers – they sing them loud and proud for all to hear.

The magic day of delivery arrives and, although you’re scared of letting your baby out into the big bad world, you know it’s time.

You want to see it soar like the proud eagle you know it is.

So you send it live and…

Crickets. Tumbleweed.

Not so much as a whimper.

Certainly not a thank you.

Hell, after a few days you’d take a stakeholder walking up to you and slapping you in the face. Even if it's for handing them such a steaming pile of dog poo, you'd take it.

But you don’t even get that.

No news is good news, isn’t it?

Well no, not in this case but (not so) deep down you already know that.

Time to check the usage stats to see what exactly has been going on. That's when the big fat zero in the active and lifetime users columns hits you like a hammer.

Right in the fleshy sore parts.

They haven’t even looked at it.

The animals. The scoundrels. The useless dirty %!!%!@ers!

All of that time wasted and it’s not like you just magically decided to spend weeks building something they might want:

THEY ASKED FOR IT IN THE FIRST PLACE!!

You have two choices at this point:

1) break down in floods of salty, bitter tears, rage quit your job and go off to tend a garden in a monastery somewhere in Nepal

2) learn one of the most important lessons of a BI analyst’s career – how to make sure what you build is what the business really needs.

As I’m not writing this using my own blood for ink on papyrus scrolls in the Himalayas you can assume I prefer option #2.

Let’s dig deeper.

Why did this happen to you?

Let’s consider why your dashboard might have been ignored in the first place.

1) Timeliness

We all know that BI reports are only as important as the amount of time left until they are due to be used in an executive pack or a regulatory return. If said time period is less than a day then the importance factor reaches maximum levels.

Did you take the original request away and spend four weeks building a full end-to-end BI solution to cover all eventualities?

It might just be that you took too long over it.

It happens.

Agree drop dead deadlines upfront and get some actual confirmation that the deadline being claimed is actually a proper deadline.

If you sit on for weeks after it should have been in then you’ve missed the boat. It doesn’t matter how good your actual dashboard delivery is.

This ship has sailed without you, my friend.

2) Complexity

It’s a well-known fact that as you keep adding more bells and whistles, the likelihood of anyone ever using it starts to fall rapidly to zero.

Stakeholders will always keep adding on more elements as you go through requirements gathering with them. But you know they'll give no thought to whether they will actually be able to decipher what the final report is telling them.

That's where you need to make your expertise felt.

I am all about the simplicity. (My website isn’t called SIMPLE Analytical for nothing.)

Take a long look at the dashboard you’ve produced and put aside your parental feelings of love for it. From a cold analytical viewpoint, have you went overboard and made it too complicated for the average user to understand?

Not the average BI analyst. The average BUSINESS user.

Remember who you are doing this for.

Just because it makes perfect sense to you doesn’t mean it won’t look like the control panel on the Space Shuttle to them.

Better still, ask your users when you deliver it for some specific feedback. Sit with them for half an hour and talk it through. Make sure they feel comfortable asking questions if they don’t understand something.

When the choice between simple and complex arises again in future, think simple. Every time.

Your users will thank you (maybe quietly and internally but they will appreciate it).

3) You didn’t ask the customer what they REALLY wanted

Yes, you may have scanned their job request form and gleaned the bare minimum of what they seemed to be asking for.

What you then went and did was take it upon yourself to decide what they really wanted. Even better, what they really should have wanted to make their working life that extra bit more special than it already is.

Problem there being that you aren’t a mind reader.

There is no substitute for actually sitting down (or getting a phone call) to go through the requirements with the customer.

I repeat: NO SUBSTITUTE.

But this is how we've always done it.

There is no excuse for locking yourself away in a tower and blindly driving on with a long development process on your own.

The general gist of proper Agile project management seems sound to me. Short development sprints, work on well defined chunks of requirements and regular show-and-tell sessions should be no-brainers in most situations.

When it comes to re-doing a badly specced job - Avoidance is always better than cure.

4) No champion

Do you remember back at the start when we looked at the problem that got us into this mess? Back about the time you hit Submit and just sent the dashboard live into production?

Did you notice how there was no mention of sending any comms out to stakeholders who might be interested in what you’ve built?

Did you not think that was strange? Of course it was. But, be honest, how often have you done it?

I know I have.

Sometimes you get so sick of a job that you just want it cleared off your plate. But if you feel like that about it, why should the customer feel any differently?

Let's say you have:

completed your requirements gathering phase correctly
set a realistic and desirable timeline for the job
AND kept the complexity to a bare minimum

Shouldn’t you already have your stakeholder pre-sold on the dashboard being a major success?

They should be shouting from the rooftops about what they are going to get their hands on.

They should be out evangelising you and your dashboard long before it hits their screen.

What if they aren't?

If you don’t have at least one champion on the business side of your request before it lands then you better double down on your post-delivery meet and greet plans.

Set up at least one feedback session about a week after you have handed over the keys to the new reports. Invite the main stakeholders to attend and encourage them to give proper feedback. Don’t let them off the hook easily if they haven’t even looked at it.

Sometimes you have to be your own champion to ensure take-up actually happens.

Better to carve out the time to do that than sit weeping because you delivered your best work and no-one cared enough to appreciate it.

How should this all work in the real world?

So how far do you have to take it in terms of:

getting the reports out quickly enough
talking to the stakeholders before you build anything
talking to the stakeholders after you build something
then making sure all the way through that it’s simple and easy enough for them to understand and use?

Each job will be different and it’s experience in the role (and your own company) that will dictate the amount of hand holding that will be required.

I understand it’s usually the coding and development phase that gets analysts interested in a project. The last thing you want to do though is ruin all of the great work you put in by telling yourself it’s the customer’s problem if they don’t wind up using what you built for them.

It’s not, it’s your problem too.

Maybe not just today when the feelings of frustration are overwhelming you either.

It might be further down the road when, despite the great work you’ve produced, some pen-pusher comes along when job cuts are being made. If they can’t find anyone at a senior enough level to vouch for the value you’ve produced over the years, what do you think the result will be?

Visibility is key.

If you're locked away tinkering in your ivory tower all the time, to the untrained corporate eye, you might as well not be there at all.

You have been warned.

Take ownership of your project and your end result.

If you don’t, who will?

If you enjoyed this article, come over to SimpleAnalytical.com for more stories, hints, tips and strategies on building your analytical skills and career.