DEV Community: Greg Brown

OctoberCMS Media Manager Fix

Greg Brown — Sat, 29 Aug 2020 02:28:41 +0000

The web is a very particular at times and for us developers, there are things that go unspoken, some "golden rules" that are so obvious to us that we forget that sometimes, the other species who share the world with us, regular humans, will also interact with systems we develop.

Please, before you get all defensive (if you are a regular human) or big-headed (if you are a developer), both of us have qualities and flaws, we are not better than each other, we are just ... different.

Anyways - I should cut back on my coffee before writing.

Developers all know the rule - files for the web should never contain spaces or special characters. Even though file systems have gone a long, long way since 'em good ol' days, where file names were 9 characters long. Nowadays, you could actually write a tweet and save it as a file name.
This flexibility has spread unevenly, with legacy systems interacting with modern systems, and the web, well, it's not a place for the faint of heart.

As developers, we should worry about file names and their compatibility. As users, our world peers also worry about filenames but in a different context, and that is when things go boom.

OctoberCMS is a beautiful little piece of software for any PHP developer (if you don't know it - I urge you to have a look)[http://octobercms.com]
I love it and use it for pretty much anything I can. From internal little projects to huge projects serving content to ~25K concurrent users, I've done it all, yet, one small oversight on my behalf cost me a sleepless weekend of troubles.

I decided to use October's built-in Media Manager to handle all my CMS related images. All was fine during testing phases, but, when we put the system online, and actual regular humans started feeding the, literally hundreds of thousands of images into the system we started facing a series of issues with special characters and spaces in filenames causing all sorts of glitches on our client's site.

After some digging and a lot of pain, sweat, and tears, I eventually wrote a little script that would rename the existing files in the system.

It was then that I decided that I needed to avoid this happening again and that I would write some code I could use in my next projects to mitigate this issue. Rather than having a personal library script, I wrote out a small plugin you can add to your OctoberCMS installation that will rename the files you upload to your media manager, to a web-friendly name.

There are still a few little options I'd like to add to the plugin, but, none of them will be breaking changes. Feel free to give it a test-drive and leave me a comment if you have any suggestions, criticism or what not.

The link for the plugin is here:
https://octobercms.com/plugin/gregorybrown-mediamanagerfix

A simple idea, automation and a deep social impact

Greg Brown — Sun, 14 Jun 2020 03:40:06 +0000

I know, it sounds like a click bait but I promise you it is not.

Some background

We all have been living through tough times lately. The pandemic is tearing through countries and continents and leaving a horrid trail of death and suffering. One of the hardest hit countries now, is Brazil. Things are particularly ugly for the less privileged part of our society. Unemployment rates soar, informal workers have lost their sources of income and, sadly, things don seem to be getting any better.
The government issued a social assistance plan with the idea of helping these families financially during a period of three months (the time they expect things to start getting back into gear here). If your family earned less than X amount of Reais, you were eligible for the assistance. Over 50 million families applied in a matter of days. When the first payment came through, people were queuing by the hundreds outside of bank agencies. It is clear that the risk of catching Covid-19 was clearly outweighed by the need to feed their family.

Making the money accessible

I work at the R&D department of a company from the financial sector and one of the lines of work they have is with regards to facilitating payments. The office has all sort of products, from simple credit card machines all the way to digital wallets.
Some bright soul at our company saw this mayhem and decided to try and make things better.
For a percentage of the people being assisted, the money was transferred to virtual account that could be accessed through an App on the phone. Payments could be done by reading QR codes.
The problem - not many retails had equipment that could generate these QR codes.
The solution - We created a simple app that could be installed on these terminals that basically would generate a QR code for the price of the purchase.
Obviously, if life could only be that simple...
For each client, due to security issues, we had to build a custom version of this app - and that is a lot of apps to build.
Over a weekend, a team was able to produce about 32 apps - no where near enough.

The power of automation

The thing that has always drawn me to computers is the capacity they have for doing, repeatedly, a specific task ad nauseam with few or no problems.

We were tasked to help out with the coding of the apps, we were told what and where to change, where to get the data we needed from. After a couple of apps, I felt that a good solid couple of hours of proper programming, could be much better applied.

Shell scripts & node scripts, some clever use of template files, and a sleepless night later, I had built a simple, nevertheless, effective little robot.

When produced manually, besides the "human factor" of mistakes being made (it was quite an error prone task if you lost concentration), the average developer could kick out 6 or 7 apps a day. My little robot allowed for a much higher output, actually churning out about an app a minute.

Social impact

After a couple of days later, we got a first report on how much our apps had helped the population, the number of transactions registered through our apps.
Through our calculations based on these numbers, we estimate that between 150K -> 300K people were able to use their social benefit for purchases without the need to stand in a crowded line at a bank door.

When you see the social impact that a simple idea and some good old fashion automation can have, it makes you wonder what else is just within your grasp that can help make the lives of people around you just that little safer and better.

Header Photo by Hello I'm Nik 🎞 on Unsplash

To do lists - you're doing it wrong

Greg Brown — Wed, 02 Oct 2019 20:08:15 +0000

They have been around for ages and, if you are in development, you've probably seen a huge amount of people using them as framework showcases.

The common to-do list is everywhere, it comes preinstalled in most modern cellphones, you have them in all variants of name and colors, whether you know it as a "check list", "task list", "to-do list", "bucket list", and so many others, they all have a common concept: write a list of things you need to do, and go crossing them off as they get done.

What if I told you that you are most probably doing it all wrong?!

Surprise time - your list is probably pretty much worthless

If your list looks something like this:

[ ] finish email
[ ] search email delivery
[ ] ....
[ ] publish in production

Then, welcome to the world of inefficient To-Do lists!

OK, I was exactly in the same place a couple of weeks ago, and it took some creative "dot connecting" to realize that this model was doing more harm than good.

Take two steps back

I've been doing a lot of reading about personal improvement lately. Form the basic "self-help" books all the way to papers on how scientists try to map out human behavior. The goal is to try and understand how and why people function in certain situations (part of a bigger project I'm working on).

I had a plethora of information, most of which was seemingly unconnected or at most indirectly connected. Then, one night a couple of weeks back, I read an article draft I had written on personal organization and somethings started clicking.

TLDR;

OK, you're probably busy, so I'll give you the express version first. Feel free to explore below some of the reasoning if you wish.

The perfect to-do list

Each item on your to-do list should consist of two things:

1 - "raison d'être", a "reason why" or an outcome.
2 - a clear action to achieve this.

Let me give you a couple of examples:

[ ] - email for client approval - adjust email layout colors to match style guide
[ ] - email 2 email service quotes to client - search viable email delivery systems

You'll notice that those are a couple of the same items I had in my first to-do list, just written down in a clearer and less interpretation-possible way.

Besides being clearer and easier for you to share this to-do list with others (if you are on a team), there is a psychological aspect that is also associated with this that will help you improve your focus on the task at hand. (I try to explain this below if you want to read)

So... what changed and why?!

Let's break one of these examples down from the start:

"[ ] finish email"

Why is this bad? I mean, if you just wrote it, it probably has a great deal of meaning to you right? You know what it entails, where to go and look for things, and so on, but, what happens to this after you've spent a day in meetings, taking notes on another couple of hundred to-do items?!

It starts becoming hard to remember everything form pointers. If you are a master of the Method of Loci, you probably won't have all that much trouble, but to us mortals...

You need a way to keep your brain as free as possible, and changing the way you write down your tasks is an incredible way of doing so.

Part One of the task - Raison D'être

French for 'reason of existence' or 'reason of being'.
I like the almost spiritual aspect of the saying... it plays well into the importance of this part of the task.

What is the desired outcome, the deliverable, the benefit you expect to get from this task? Is it clear? Is it well defined? Is it an action, a tangible or intangible? Again... is it clear to you what is the reason you are writing down this task?

If so, great... you can go on to Part Two, if not, then you must break it down some more:

Too many outcomes? Break them apart into smaller tasks.
No outcome? Re-visit the task - does it require your attention? Is your understanding about the task clear?

Here are some bad examples:

Task: build site

This task says nothing, building a site is not trivial, even for an expert programmer. There are many moving parts and the outcome is way too generic.
You should break this task up into smaller tasks, with clearer deliverables and outcomes:

Task: responsive site header following style guide

Task: re-usable site header snippet

Are examples of a simple break-up of the tasks you could get from that.

What I want you to get from this? Please note that these "tasks" are deliverables. They are things that you can "touch" or "see". They are "real" things. This is an important aspect because of the way our brains usually function. (see "The brain" further down).

You might look up at the TLDR; section and say - WAIT A MINUTE:
email 2 email service quotes to client is not a tangible thing... it's an action... you are breaking your own rules!

Well... yes and no - some "things" come naturally to us - by looking at them we are instantly reminded of the deliverables and what they entail. Send quotes to client implies to most modern people, that you must send the quotes via e-mail or communication system of choice, to the client, and hence, you must produce an email, and send it. We've grouped two tasks into a single one, but the deliverable is still the email with the system quotes.

Part Two - A clear action

Now that you have a desirable "thing"... what is it you must do to accomplish this? What is a clear and simple action that you must do?

Please note that you don't need to go into the tiniest details of how to achieve this, just a simple general action you must take to ensure that your deliverable is done. That said, any point of importance should be here! Adjust layout colors to match style guide is a clear and direct instruction. It is not open to interpretation or does not require you to remember that you needed to match the style-guide.

In a nutshell

Your task list should be composed of a list of deliverables, with clear actions and observations as to how to achieve each one.

The Brain

The brain is a funny little thing. There are some well discussed and documented facts about it, specially with regards to how we store and retrieve information.

We work well with "images", "stories" and "feelings". If you try to memorize somebody's name; you are more likely to do it if you associate that name with an image or some funny story. It's the principle of the Method of Loci for one... you link a memory to a visual image, and it comes back to you.

DISCLAIMER

Since I am no neuroscientist or psychologist or anything related to science of the brain in any way, please read this with a pinch of salt.

Loci states that one of the keys in memorization is to frequently re-visit the palace in your brain, in order to refresh the memory of things you have stored, and hence, sediment the memory into your brain. Inadvertently, we do that with our unclear lists. We are obliged to read them and "remember" what it was we needed to do.

You work at your best when you focus. Focus let's you center all your attention on a single task. If your brain is "free of clutter", you may focus with greater ease because nothing distracts your brain from the task at hand.

By altering the way you create your to-do lists into a more "non interpretive" model, you can quickly gain important information about the task without requiring your brain to do the heavy lifting.
Since your brain is not required to work so hard keeping all those "memories" alive, you are more free to focus at a single task.

As you go getting used to the idea of relying on an external system, you are less inclined to worry about your to-do lists and hence focus more on the task at hand.

Think of your contact list on your phone. A decade ago, we would have memorized dozens of phone numbers, nowadays, we seldom do, thanks to fact that we have a reliable and accessible system that makes calling somebody trivial.

A simple change, with a huge impact.

Hiring a developer - Part three - How to conduct interviews

Greg Brown — Tue, 03 Sep 2019 00:41:14 +0000

We have reached part three of my "Hiring developer" series, and boy... this is a big one.

Previous Articles in series
When to hire a developer?
Where to find developers

Intro

I've been in a management position for the better part of the two decades I have worked with development. From a simple team manager, with little or no influence as to whom and when I would hire somebody, up to actually hiring the people responsible for hiring people.

I'd like to say that I have a 100% record of successful hirings, but that would be a lie. Over the past two decades, both as an employee and as an employer, I've learned a lot about hiring developers, and I'd like to share with you some of my processes and ideas.

In this series of posts, I'll show you how I tackled all these questions and more, over the two decades I worked in advertising agencies.

Disclaimer: This is not a definitive guide on how to hire a developer and I am not saying my way is the only right way to do it. There are thousands of other methods, scenarios, conditions, and so forth, where my processes will not apply.

How to conduct interviews

This is a subject that always generates a lot of controversies and I plan on looking at this topic through my optics. I'll try and explain what I feel is important when I hire somebody, what I feel is essential and what I feel is negligible. Again, this is not a cake recipe that you must follow exactly, it's merely my way of doing things.

Getting ready for the interview

Resume (CV)

The resume can tell you a lot about a candidate if you know what not to look at. I know it sounds strange, but I've seen too many times in my life, people dismiss potentially great candidates for the strangest of reasons such as where the person lives, age, horoscope(?!), gender, and so on.

Work history is the first thing I look at. What has this developer done in the past and for whom? How is the text written? Spelling mistakes? Correct use of grammar and language? Is it overly formal or informal? Does it sound authentic? Grab a phrase out of the CV and google it. Is it a copy & paste off somebody else's CV? (You'd be amazed at how many times I've had positive hits).

If the work history sounds credible and in line with what you are looking for, what is the age of the developer? I mean, if he has 15 years of experience, and he's barely turned 19, you've got either a friggin genius or...

Finally, depending on the level of the job offer, I'll look into references. It is always good to have a good long hard look at these. Whenever possible, try to cross-reference the details. What I mean is, if he says John Doe was his boss at Acme, try and lookup John Doe on LinkedIn and double-check to see if his work history actually corroborates this. I've had developers put neighbors, friends and, relatives as references, with no work history what-so-ever. Double-checking references can point out some useful things.

I seldom look at anything else. Some companies have policies for only hiring people with degrees. I don't particularly like that policy, but there are times one can't really go against company policies all that much. If my company has that policy, I don't really mind where they got their degree from... I have seen people coming out of high-end universities who barely knew a line of code, and people out of really obscure and poorly rated colleges be great at anything you threw at them. I find it important to note that a CS degree is useful and I am in no way stating that going to university is a waste of time and resources, I am just saying that it may be a tad over-valued at times.

I really shouldn't have to say it, but just in the hope that this paragraph will clear up any silly ideas... You should have absolutely no restrictions, biases, preferences, likes or dislikes with regards to gender, color, religion, sexual orientation, culture or political beliefs. There is absolutely no justification of treating anybody any different because of any of these details.
If you are considering restricting your development team in any way based on any kind of discrimination, you should step down from a management position and get some help.

Getting in the mind of the developer

I have some things I rank high on my value scale. Among the top ones are loyalty, professionalism, honesty, and commitment. These all count a great deal when I'm looking at hiring somebody, especially because I want people working with me who can be trustworthy and accountable.
Even before I sit down to talk to somebody, I already try to extract some information about them. How quickly can they schedule an interview, what time they can schedule the interview, the language they use over the phone and how they respond to questions over email are just some of the things I look at.
Communication skills here are a great thing to look at. How much does the person you spoke to sound like the resume you read? How formal or informal are they? How articulate is the person?

If a developer is working a full-time job at a company, how will he sit down and do an interview? Will he, in his current company, call in sick? Will he schedule a time that does not conflict with his work hours? How quickly can he start working for me? These are all things I take into consideration even before the interview is scheduled.

An example: if a developer tells me he can't schedule an interview in working hours because he has a full-time job, I consider that a reasonable request on his behalf. I prefer somebody to tell me that rather than just skip a day at his current job.

Other things include: How quickly he can begin? If he's ready to drop his current job, what is his role in the company? What are his attributions? What's still on his plate where he works?
I've had interviews with developers who were in the middle of a project as lead developers and say they'd start in a day or two, all because of a salary bump of a couple hundred.

That kind of behavior does not inspire confidence unless it is backed with some serious reasoning. Again, it's not a conversation killer but rather a point I'll probably try to bring out during the interview. Something I would like to understand and contextualize before hiring.

I like to have an idea of who the developer is, his principles and general outlook towards work before we sit and talk. There are literally hundreds of little details you can pick up from emails and phone calls. I usually make note of the ones I feel might need some digging into and keep them as conversation topics for the interview.

Rapport (is it psycho mumbo-jumbo?)

Rapport is one of those things that a lot of people frown on. Some think it's psychology-mumbo-jumbo, others think it's a technique used by shady business owners and pick-up artists. I'll later write something on rapport since this is not the main topic of this article, but a TLDR; version for this context would be:

Rapport is established when both parties feel comfortable at exchanging ideas without the feeling of being judged or looked down on.

Where the operative word of this definition is comfortable.

I have a strong feeling with regards to my intuition. I guess in an unconscious level I do all sorts of body language analysis (I did do a lot of studying on the subject back in the day), which helps me guide the conversation.

Your posture matters

It is your job to make the developer comfortable. From how you welcome the interviewee down to how you sit at the table, it all portrays a message. A great part of that is achieved by paying attention to what he is saying. People like being listened to. If you're going to sit there with a laptop and type away when he is telling you something, you're off on a wrong foot.

Phones

There is no justifiable reason to keep answering your phone or texting people during an interview. It is disrespectful and plain-out rude to your candidate. If you do need to answer a text or a call, it should only be in an extreme situation.

I usually leave my phone on mute and face-down on the table. I also block my calendar leaving it clear I will not be answering calls or texts during interviews.

Computers

Computers can be a great tool if you want to discuss something that your developer has produced or if you want to show him some presentation or technical issue. That is it. You should not have your e-mail client, your instant messenger, WhatsApp web or anything that will potentially call your attention away from the interview. I'll say it just because... Once you have used the computer, put it aside. You are here to interview somebody, not fiddle with the notebook.

Breaking the ice

I usually start interviews with a simple introduction and asking candidates to talk about themselves a bit, and give them some pointers like: what can you say about your work? Tell me about your latest jobs, or something to that line. (I've had experiences early on where developers would tell me stories about their pets or how much they enjoyed surfing - even though some stories were even fun, they were hardly objective).

Sometimes, depending on the candidate's initial behavior (some candidate really struggle with interviews and become excessively nervous and/or insecure), I'll give them some context of the job offer, company, and me in order to make them at ease. Creating a safe initial environment is key to a productive interview.

Establishing a communication exchange

Again, I'll look at posture, general articulation, signs of nervousness and other little tell-tale signs. If I feel the developer is still insecure or worried, I'll take charge of the conversation every now and then to try and make the candidate feel more comfortable. Some respond to humor, others respond to knowing things about the current company. It's a question of feeling your way around the conversation.

With a quick back and forth of exchanges, your goals are to give your candidate an assurance that things are OK and make him comfortable enough to open up to you in a franker and less mechanical way. There are few worst things that having a candidate answer mechanically and as if he's memorized answers. In my opinion, these kinds of responses beat the purpose of interviews.

How technical to go?

I don't tend to go all geeky and technical without a context. I like to ask about past experiences, something that's on the candidate's Github (if there is one) and things like that. I refrain from pulling out a "questionnaire" full of trick questions on the languages I'm hiring for. If I cannot use any of the past experiences to validate initial technology vetting, I'll create a couple of scenarios our candidate can try to wiggle his way out of.

Usually, the higher the position, the more tech vetting I'll do, yet, I am not a fan of code challenge tests. I particularly think that a developer who can solve a problem by suggesting three or four options is usually better suited for my needs than one who can recite an entire "node js" book by heart. Again, this is my way of thinking and fits within the team profiles I usually build, where adaptability and problem solving usually far out-weigh specific technical knowledge.

Code Vetting

I usually do some sort of code test during the interview. For more inexperienced candidates (for junior positions or interns), this is usually something that will give me some insight on what the candidate knows and does not know.

When we are talking about mid-range positions, where your developer needs to know certain things, I do tend to give them a couple of scenarios to work on. These are usually tightly related to our business. I tend to keep them short and simple. The idea is less "code an answer to this" but rather, tell me how you would solve this issue. I seldom use computers during these interviews.

Test Jobs

Yes, this is a thing. I personally hate it and would never really do it, but it is something that is becoming more frequent.
The concept is: you send a briefing to a number of candidates, the one who performs the best job gets hired.
What actually happens is that companies are abusing this concept. I have had friends who did challenges like this one trying to get a job, they never got the job, but after a couple of weeks, saw their work published for one of the companies clients.

Technical aid

You are probably a manager of some sorts, and you are probably no longer obliged to know every little dirty secret of the languages you are hiring for. If you need to hire for a very specific technical position, take along a technical aid with you. Bring in one of your lead developers, properly prepped for the interview. Also, sometimes, it can help to create a better dynamic in the interview.

The same applies if you have an HR department in your company. HR is somewhat designed to excel in these situations. They can bring invaluable insights, questions and help guide the conversation, especially if you are not used to interviews.

An added benefit, you'll have somebody to bounce off ideas with once the interviews are over.

The money issue

As a candidate, I used to hate sitting down for an hour-long interview, only to find out that the company wanted to offer me well below what I was expecting. It is actually worse when you feel that you like the company because it seems that they don't value you. I also have faced situations where I was unofficially offered a position at a value, and after the interview, they tried to play down the value saying that the value was never set in stone.
Since I know how horrible it is to be in such situations, I'll make sure that the interviewed knows, beforehand, what he is applying for and how much we are willing to pay.

Money usually comes up early in my interviews - when I confirm that we are on the same page of work conditions. If there is any negotiation, it better occur sooner than later. Once I feel both candidate and I have sufficient knowledge of each other, I'll bring up money and work conditions. If the candidate is put off by anything, this gives them a clear chance of breaking free early. If they banter for more, I usually already have sufficient knowledge to know if it is worth negotiating or even if it is worth continuing with the interview.

References

For more specialist positions or for senior devs, I will always reach out to previous employers or co-workers. I usually like to do that a couple of days after the interview. This is something that can be easily achieved with Linked In.
References are, in my humble opinion, one of the best ways to learn about your potential employee. With the right questions and conversation steering, you can validate a lot of information about a candidate. This takes into consideration you've already double-checked the references in the resume.

Keep your eye on the prize

What it is you are hiring for is something that you must always keep in mind.
You must think of where the developer will be working, will she/he be part of a team? Work solo? Will there be requirements to talk to suppliers or other teams in different areas? These things are often overlooked and can lead to disastrous results.

Ending the interview

Who has never sat down for an interview and seen it's going nowhere really quickly? Or worse? Who has had such a good interview, it could go on for hours? Knowing when and how to end one is a fundamental part of interviewing. I've had developers say they thought they were not getting the job because of how the interview was ended, and I've heard people saying they were sure they were going to get hired because of how the interview ended (even though they were nowhere near getting hired).

Signal that the interview is near the end. Ask them if they wish to add or ask something that has not been covered or something to the line. Don't end the interview abruptly. It is not considered polite and respect is in order.

One thing I try to do is to end my interviews in a neutral tone. I don't like to get hopes up or down straight away. Since I probably have more people to interview, I leave it clear that there are other people being interviewed and give them a realistic idea of when they can expect an answer.

Feedback

This is something most companies are horrible at. As a candidate, you went to an interview, you got worked up, you are hopeful, waiting for what seemed to be a great interview, and then, you wait...

Answer every single person you interviewed. Starting off with the person you plan to hire. Once he is hired, get each candidate and thank them for their interest. Explain in a polite manner that unfortunately the position has been filled. If possible, write each email out individually and personally. One of the worst things is getting a generic email that is mass-mailed to you stating that the job offer has been closed. It shows no respect and consideration! Remember, you called the person for the interview, the very least you can do is be respectful.

Conclusion

OK - That was a long one. I could probably write articles on each of the main topics here, but I think I got the basics covered here. The next and final article will give a brief overview of how one should get ready to welcome the newly hired developer.

Quick and easy alias for Laravel

Greg Brown — Mon, 26 Aug 2019 22:55:56 +0000

Alias for PHP ARTISAN

If you are on a Linux or Mac machine...

Open up your ~/.bash_profile with your favorite text editor and add the following line at the end of the file:

alias a="php artisan"

Save the file and load it for the current terminal profile with:

source ~/.bash_profile

- the next time you log onto a terminal window it should already be working

Lazy 'php artisan'

Now instead of typing in all those nasty characters 'php artisan' all you need to do is type a followed by your favorite command!

instead of typing:

php artisan view:clear
php artisan queue:restart
php artisan make:controller

You can now do:

a view:clear
a queue:restart
a make:controller

Isn't that a blessing?

Hiring a developer - Part two - Where to find developers

Greg Brown — Mon, 26 Aug 2019 22:32:35 +0000

This is part two of my "Hiring developer" series. Please check out part One for more insights.

In this series of posts, I'll show you how I tackled all these questions and more, over the two decades I worked in advertising agencies.

OK So where can you find developers?

This is a very personal thing I guess. Some people will use hiring companies, others will scour the internet forums searching for people, others will filter LinkedIn and other developer sites, open job posting in development-related sites, and, the list goes on and on.

I personally usually found my developers on social media. I might not be very active on Twitter, Facebook, LinkedIn and the liking in terms of participation and contribution, but I do keep up to date. I read posts, I am a member of a number of development communities, and whenever I sense I might need new developers, I go to meetups to get to know people.

HR departments

I've had a few experiences with HR departments. As a manager, with a lot of things on my plate, HR was invaluable in terms of organizing interviews, working papers, bureaucracy, and other time-consuming stuff. That said... the developer is a highly specialized job and as a manager, you are supposed to understand that. You cannot get somebody in the HR department who has little technical knowledge to filter out potential candidates or be responsible for describing the job to post at forums or job sites.

If you are lucky to have an HR department, remember you are responsible for the job description, you are responsible for filtering our applications, you will be conducting interviews. Don't delegate this to the HR department.

Job Posting Sites

There are hundreds of them. Your country probably has region-specific ones, even Google has started scraping for job offers and returns them as a search result. These sites fall in, basically two different categories:

Pay to post Jobs - These are sites where you, as a company, pay to post a job (it can be a monthly fee or by job posting). These tend to have a higher number of responses since developers don't have to spend money to search the jobs.
Potential employees paid sites - These sites are open for you to post job offers, it's the people looking for jobs that pay a fee to be eligible to look at the jobs. These sites tend to have lower response rates.

In my experience, both have reasonable results and there is no real difference in terms of the quality of the people sending in applications.

Social Media

Finding developers on Social Media can be a daunting task. Each social media has its own particular way of working and I'll try to skim over the basics of what I do on each. Even with these pointers, this is something that works best over a longer period of time. You find developers that spike your interest, follow what they have to say, and when you think the time is near, talk to them. It's usually a bit frustrating since a large part of the developers you seek will wither not be interested, but, they might point you to other equally qualified people.

Facebook

I find that joining groups of interest is by far the best way to seek developers. I personally look for two things when searching: an apparent understanding of the topic and the general behavior online. Let's say you are in a group of Javascript; you'll look for developers who seem to ask and answer questions that are sensible and coherent with whatever position you are looking to fill. You would not want to hire a programmer asking how he can add two numbers in javascript for a senior position, nor would you want to hire somebody who answers things completely wrong for that matter. The same is true for a quick personality check, if the developer is rude and/or aggressive, he probably won't be a good fit for your team. I prefer to talk to people who either answer in technical terms, or people who seem happy to help, but not with excessive joking.

Twitter

Twitter has a harder search curve. I usually search for hashtags, look at peoples comments and so forth. The same rules apply. Avoid people who troll others, avoid people who ask questions that seem too far from the profiles you are searching.

Some argue it's not a Social Media, some may argue it's a job posting site. I feel that depending on the way you use it, it can be both. Looking from a social site perspective, you can find people usually by searching developers you know. Find 2nd and 3rd-degree developers, search their history, see if they are active on other networks and so on. Some have recommendations, and those might be helpful, but it is important to check who has left them.

Github

I seldom use Github as a form of judging a developer. I myself have almost my entire work history on wither private GitLabs or private BitBucket repositories. I have a handful of things on GitHub I haven't updated in ages.
If a developer I am looking at has an active Github account, I will skim through the code to see if I can spot anything out of the box. That being said, I will rarely use Github as a deciding factor for calling a developer for an interview, I would rather use anything I find there worthwhile mentioning as part of the interview process.

Consulting/Talent Firms

At least here in Brazil, there are tech-oriented consulting firms, that will "lease" you developers for a period of time, or allow you to hire them at a fee. This does eliminate a part of the work of searching for developers, but, does come at a premium. You'll still be faced with hours of Resumee reading and interviews. I've had experiences that were both great and horrible with companies like these; I once interviewed over fifty candidates for a senior java backend position, spent several days in interviews where most of the developers knew less about java than I did.
I eventually found a developer through an acquaintance on LinkedIn. I also found a couple of gems in rough through companies like this. People who showed huge potential and eventually got hired by the company.

Inflowing developers

Having "Careers at [office name]" or "Come work for us" on your site and social networks can be a way of attracting in developers. Have them send in resumeés and fill out updated contact details (you'd be amazed at how many developers don't update their CVs after they've changed phones and emails). If you've got a good inflow, you can sort out who to keep an eye on.

All in all, the process for searching candidates is time-consuming. To find the correct people for the job requires patience, hard work, and some luck. If all goes well, you'll have a list of candidates that are worthwhile calling for interviews and that's the topic of my next post, how I like to conduct interviews.

Hiring a developer - Part one - When to hire a developer?

Greg Brown — Fri, 23 Aug 2019 19:13:56 +0000

In this series of posts, I'll show you how I tackled all these questions and more, over the two decades I worked in advertising agencies.

Disclaimer: This is not a definitive guide on how to hire a developer and I am not saying my way is the only right way to do it. There are thousands of other methods, scenarios, conditions, and so forth, where my processes will not apply.

When to hire?

The first real question. When should you consider hiring a developer for your team? I have found that most companies go about this the wrong way. There is a tendency of only hiring new developers when your current team is swamped and on the verge of Burnout.

This is not the way to go. I've always strived to keep my team with a 70%-80% workload. This can seem like a waste of money for some, but I've realized that developers, like any other human, need time to think and to decompress. A healthy (both mentally and physically) developer, will churn out code better and faster than an overworked one.

An added problem to hiring people when your production level has reached its peak is; your new developer will need some time to adjust, get to know his place in the team, understand work processes, and so on. If all your devs are freaking out with work, tired, mentally exhausted, and, behind on their work, it is very unlikely that your new developer will get the attention he/she deserves.
Actually, it's more likely that the developer will get overwhelmed with work, and instead of developing at full potential, he/she will be swept away by the tide and add little to the team. Congratulations, you've just hired an employee about to burn out too, and not to mention, you've just added more overhead to your existing exhausted developers.

PLANNING IS KEY

You most probably have some control over what your team is up to. It's up to you to know what are the Key Performance Indicators(KPI) of your team's output. What the basic feeling of the team is, and what are the upcoming challenges they'll probably be facing in the not-so-distant future. If you don't, then I would suggest that you, before hiring new developers, at least get some organization in place. Know what to expect from your team, figure out how to qualify what they deliver. It will pay off very quickly.

A tangible example

I worked in an advertising agency and most of my projects had the following characteristics:

They were short-lived (which meant little or no maintenance).
They fell into three general categories - common company sites, promotional sites, and bleeding-edge technology sites.
Time to market was usually very short.
Demand was a bit sporadic.

From this, I had a few KPIs I would assess my team on. The main one was the number of iterations I had with the Q&A department. If they had many issues with my team's delivery, I would know something was off. There were a few KPIs I used besides Quality, another one was code libraries for re-use, and obviously, conversations with my team.

Besides the occasional demand surge, I knew roughly how much work our team had each month. I also knew how negotiations with clients were going and I had time to plan.

Replacement

People change. They might have been promoted, had a better offer, they might be pursuing a life long dream, they might lack challenges, or they are just looking for a change.
Whenever that happens, I personally prefer to replace the developer with someone from the team. Let's say my senior developer quits; I'll usually prefer to "upgrade" a mid-level developer to senior-level rather than hiring an external resource. I'll fill the opening with either a mid-level or junior-level and let them grow. I find this is the easiest, both on the team and with the new developer. (Added bonuses include: you are bringing in a fresh mind that can have time to adjust to company culture; people in the team see a clear chance of growth; teams usually deal better with welcoming lower-ranked developers rather than adjusting to higher-ranked ones - again this depends on your team).

Obviously, it's not always possible to do this, and sometimes you'll need to hire a replacement for that specific opening. When something like that happened, I usually talked to the team before hiring, and whenever possible, had the team participate in the hiring process. It makes for a smoother transition.

Finally, on replacement, don't replace a developer because he/she is currently under-performing without giving it the required time and thought. Sometimes, people just are going through people problems. Talk to your developers, understand where they are, why they are where they are and align expectations. You'd be amazed at how much better a developer can get if you start treating them like people rather than machines.

Growth

If the demand for your team is on the rise, you'll have to hire new staff. If you have some planning, you'll know when to do it, it's usually a no-brainer. If your team is efficient and no optimization can supply this demand (by automating tasks, using tools and so on), then you'll need to grow.

Temporary growth is not a reason to hire

If you are hit by a huge surge in demands, like I was a couple of times, you have options like freelancing, temporary contracts or even hiring companies. I don't think I ever hired a full-time employee in this scenario. Hiring with responsibility is a key factor. You are changing someone's life. They are changing their life based on a job offer you gave them. If you hire them, just so that you can let them go 90 days later, you could have just hired them as a temp. In a nutshell - don't do to others what you don't want done to you.

Specialization

I've had situations where a client would have a very specific need and we had to hire somebody with that specific knowledge. I am not extremely comfortable with this kind of hiring, as, inevitably you are linking an employee to a very specific scenario. Any change to it could mean having to let go of the employee.
Discuss options with your team before going down that road. Hire a temp or a consultant to give you some time to assess the field. Again, it boils down to responsibility.

Oportunity

In Brazil, we have an expression "Mosca Branca" (literally translates to White Fly) which is used as an adjective for extremely rare. It's the equivalent of a four-leaf clover I'd guess.

There might come a time when you will bump into a developer that simply blows your mind. I had that a couple of times in my career. We would outsource some jobs, and there were two occasions when the freelance developer was just so amazingly "a perfect fit" with our company and team that I brought them in, independent of actually requiring them at that time.

Again, I had two of these in over twenty years. I also must mention that one of these hirings back-fired. The developer soon discovered that he was better suited as a freelancer than a fixed employee.

Conclusion

If you got this far, I guess you've seen a common component in most of the scenarios: planning.

Plan your hiring. Don't go wild and hire two dozen developers to create a single e-mail marketing HTML. Also, don't overwork your current team and suck them dry to the bone. Keep in mind that each developer is, above all, a human. Replacing developers in your team is a costly procedure. It costs the company money, it costs your team time and emotional strain, it costs the employee and yourself time and stress.

Make sure your team is well organized and as efficient as they can be before going down the hiring road. Adding developers in a messy and inefficient team will, 9 times out of 10, create more mess and inefficiency.

As I said a couple of times above, be responsible. As a manager, I have always looked at a developers job as something both the developer and I were responsible for. With that in mind, communication has always been an essential component in the work relationships I have had. With an open communication channel with your development team, it is usually crystal clear when you need to hire new staff members to ensure that the engine still runs smoothly.

How being a developer made me a better baker

Greg Brown — Tue, 06 Aug 2019 21:07:18 +0000

I was inspired to write this article after I saw a tweet where the user was unsure if he should start to learn development. He argued that his wife was worried it would suck out too much time of their life and that he would only end up being frustrated and jobless as the market is extremely competitive.

Some Background Information

I've been programming since the age of 10 when I was first introduced to the Apple][+ way back in the 80's. I still remember the program I was taught.

10 HOME
20 PRINT "GREG"

From that day on I was hooked and spent pretty much any time I had available on the computer.

That said, I did still go to school and have other chores like "doing my bed", "clean-up the mess", "do the dishes" and, so many others. I hated them, especially the "do the dishes". When I hit my teens, I found a loop-hole in the chores, where if I helped cook, I was not required to do the dishes and, that's when I started falling in love with cooking.

Fast-forward the odd thirty years. I was working in an advertising agency as an operations director (not my dream job), but still had all of my childhood passions in check - development was still a core part of my day-to-day and I would on occasion, whip up something strange and unique in the kitchen for friends and family.

My wife who worked with me had, accidentally, started a business making cakes (this is a whole story in itself). During the early days, my cooking history was of little use since she did not trust me around her cakes and constantly monitored anything I did. As time went on, the developer in me started looking at ways to tweak recipes.

In no time, I became the head baker of our cake-shop - you can look at some of our creations over at @cakestudiobr - creating recipes and ideas that, besides being loved by our customers, were personally complimented by a two-star Michelin chef and got us first prize in a Reality TV Show here in Brazil. (OK enough shameless self-promotion).

How does programming make you a better baker?

I would argue that there are two key factors in which being a programmer will make you a better baker (or pretty much anything else really);

1 - Being curious and a keen observer

From a developer perspective - Programmers develop a tendency/talent of identifying patterns. Curiosity moves them to do this. Looking at code, understanding what it does, looking for how and why something works. This is something that comes with experience and no doubt some knowledge, but, I would argue that experience plays a bigger part in conditioning your mind to work in this specific way.
In programming, we identify patterns and flows, we understand how components interact with each other and how these things sum up to create whatever outcome. We also understand the importance of order, inheritance, dependency, and, so many other little nuances that make our job one of the greatest jobs in the world.

From a baker perspective - this level of observation, this understanding of the way that components interact, and, the curiosity of how everything ultimately fits together to get to generate whatever outcome we want is as important as it is in development. From understanding general concepts like sugar to flour to liquids ratios, down to understanding the effects of gluten activation or the protein structure of egg whites, these are all little components of a program that must, very much like their digital counterparts, be treated with the same amount of respect and love.

2 - The urge to create new things with what we learn

From a developer perspective - Whenever a developer learns something new, there is an almost impossible-to-resist drive to go out and try to use this knowledge to build something new and shiny, to test where, when and why to use this. This inevitably leads to failures and frustrations, but also leads to solidifying the understanding of a given concept or knowledge.

From a baker perspective - I could actually say that it is literally the same motivation and process. The need to apply the knowledge, the willingness to test and fail, the urge to understand the sometimes complex chemistries involved in baking a cake or some other sweet goodie.

So what?! I am not a baker!

If you got this far in this article, you either grasped something interesting about being a developer or you actually just read the sub-title above and wanted to get to the TLDR bit of the article.

You do not have to be a baker to benefit from the disciplines learned by a developer. The curious nature of a developer, looking for patterns, trying to understand how each of these components work, how they all interact together, how you can extrapolate this knowledge to find new applications for it, or know when to use a determined piece of knowledge is applicable to pretty much any job you can imagine out there.

I would argue that a great part of development is, basically put, problem-solving, and problem-solving is a mixture of seeking knowledge and applying this knowledge to address the issues identified. Becoming a developer (and I am not saying you need to develop a new operating system or program artificial intelligence systems or whatever) is about learning to look at things from a unique perspective. It's about trying to understand something to its core and then trying to act on that to create something that will make your life better.

If you can relate to that feeling, then, you might just look into learning development.

(We have since sold our cake-shop and are no longer producing, at least professionally speaking, cakes and desserts).