Category Archives: Community

Functcon

TL; DR

We believe that Functional Programming (FP) is going to be, and is currently, a disruptive force in mainstream programming. We want to help shape the community around that force to improve the larger software community. We will do this by building an open and safe community where newcomers and veterans can explore FP- their love of it, and how to use it to build awesome software. If you believe in this please sign up on the mailing list at www.functcon.com.

@Functcon is a #FunctionalProgramming #Conference built around a community of #safety. Click To Tweet

Our Value Statements

To promote a culture of success and safety to a growing community of functional programmers, we believe the following things:

  • Functional Programming is disruptive and will continue to be so.
  • Psychological safety is the most important thing to build a successful community.
  • Excellence in programming makes changing code safe.
  • Processes of continual improvement are necessary to achieve excellence.

Functional Disruption

Kate, my wife, and I believe very much that Functional Programming is a disruptive force in the programming industry. This old technology is seeing increasing attention as we are needing different approaches to solve today’s problems.

The simplest computers are gaining more cores and an application’s ability to use those cores determine its success. Not to mention the kinds of thoughts needed to solve the problem of analyzing the increasing mountains of data we are accumulating by the minute. These problems are a couple of examples of problems that have been difficult to solve using Object Oriented Programming (OOP) or Procedural Programming.

We see it as every mainstream OOP language starts to gain FP language constructs.  FP is appearing increasingly in podcasts. Functional Programming conferences are starting to appear and be successful with multiple hundreds of attendees.

We do not know if it will ever displace OOP, but we believe it will become as important. This means that to prepare for the future the industry will need people training in this skill set right now. The Dark Matter Developers are currently not learning this skill. You can see this by looking for accredited courses. Companies are not paying for accreditations in FP.

Dark Matter Developers are the strong majority of developers out there. That means there is currently a building skill deficit. As this skill becomes more in demand the culture surrounding that skill will become in demand. As a community, we can build a culture of success and safety.

Psychological Safety

Psychological Safety was defined by Amy Edmonson as the shared belief that a team is safe for interpersonal risk. She discovered teams that had this trait were the highest performing teams. Later Google found in their research that one of the most important traits to define a successful team was Psychological Safety.

For Functcon, we want to expand that definition from team to community. We believe by focusing first on Psychological Safety, we will build the most successful community.

Excellence in Programming

Excellence is not a word I like, as I state here. So, let me define what I mean by excellence. Excellence is the application of the most current knowledge about the best techniques and practices with understanding that the most valuable part of a project is its maintenance.

We believe by focusing on the very best of FP with this understanding of maintenance we can grow a valuable community.

Continual Improvement

It is virtually impossible to make something perfect, especially when you are dealing with a complex system. Everything you do is going to involve tradeoffs. Everything you do is going to be relevant to a given context which will move on and change under you.

So, we believe that Functcon needs to be about the continual improvement of the community, the code, functional programming, and itself. This will allow us to adapt and always remain at the top of the game.

Tying it together

If we manage to be the most successful community, with the most valuable practices, and we can adapt… Well nothing will be able to stop us. However, we don’t need to be the best to make an impact. If we even start to approach these things we will make for a better industry. Let’s do it together.

Call to Action

If you like what we are trying to do, please sign up for our mailing list. These names help us attract companies to help pay for the conference. Please tell your friends about us. Our page is www.functcon.com. And, of course, we won’t sell your information. Come hang out with us today!

I joined @Functcon mailing list. #Awesome #FunctionalProgramming #Conference https://functcon.com Click To Tweet

Making a safe place to work

Thanks

This post is a special thank you to @JoshuaKerievsky. First I do not work with Joshua, or am I associated with him, however he has inspired a large amount of good things within my team.

Safety is a Skill

Bringing safty to the place I work is one of my highest priorities. Now to be fair, my place to work is the most safe place to work I can imagine. So why do I focus on bringing safety to my work?

Safety is a skill. It is why all manufacturing companies have manditory safety training. But these trainings only cover one type of safety.

Phycological Safety

Google discovered that phycological safety is the key to a well functioning team. We have seen simular successes in our team well before this article was written.

Core Rules

My team’s core rules have been in place for almost 4 years (as of September 2016). They focus on building phycological safety. They are:

  1. Treat everyone with Kindness
  2. Treat everyone with Consideration
  3. Treat everyone with Respect

The first thing to notice is the word everyone. This is not just those you work with. It is not just the people within your department, company or developer community. It says everyone, and it means everyone. It also means that everyone you work with will do the same.

The Cards

I won a raffle held by Industrial Logic, Joshua’s company. The prize came with a small number of these cards:

The back states you have the autority to stop work if any of these things are at risk:

  1. Time
  2. Information
  3. Reputation
  4. Money
  5. Health
  6. Relationships

I instantly fell in love. I gave each member of my deportement one of the cards. I made discussing the cards part of the on boarding process. At the end of which I gave the new hire the card.

On Boarding with Safety

I inform every employee that they have great authority when they come to work here. They can stop work if they feel the any action anouther is taking threatens any of those things. I then express how our practices, Test Driven Development, Contiuous Integration, Mob Programming, and others help to protect these things.

The new hire now has the authority to stop our work if anyone violates these practices and the reason isn’t to experiment on a better way; and even if that is the reason.

Then I tell them the hard part of this authority. They do not only have the authority, but the responsibility. It is part of the job requirement that they do this. Ignoring these hazards is willfully not doing your job.

One of the best moments of my career was when I told this to our interns. They could not believe any company would give them such resposibility and power.

Part of our culture

A number of us have attached the card to our badges, as a reminder of how important this really is. We retrospect often and try to do things that promote this safety. I think we are better then any company I have ever heard of it this regard. However, I do not believe we are perfect or finnished. The company recognizes that this safety has obviously contributed to our success and we are dedicated to finding better ways to achieve it or grow it.

A Better Interview

As interviewing is the first impression a company has of a candidate and the first impression a candidate has of the company, it is important to get right. My goal with this article is to start an open discussion about interviewing and how we can improve it. As a community we need feedback, debate and understanding to create something better. The place I work currently has the best interview process I have ever seen in my 17 plus years in this field. By examining what they do and why, the discussion can open with a solid foundation. We can build upon this to achieve something greater.

Where do we Start

The Hunter Software Development Group is built off of three core rules, and those rules permeate everything we do, including the interview process:

  1. Show everyone kindness.
  2. Show everyone consideration.
  3. Show everyone respect.

These are our foundations upon which we build everything. We believe every facet of an interview process should be executed with these in mind.

Our Objectives

When you consider kindness, consideration and respect as the foundation for an interview, your goals change shape. Yes, you need to know if the candidate is right for the job, but how you determine that changes subtly as your focus changes.

There are three conditions for an interview being considered successful:

  1. The candidate leaves feeling fairly assessed.
  2. We know if the candidate will be a good fit for the team and company.
  3. The candidate knows if the team and company is a good fit for them.

Achieving those Objectives

Each objective is achieved through very intentional means. We examine our process after every interview. We look for any place where the process can be polished, or someone can be better trained. We focus on each objective to better our process and make the interview successful for both the candidate and the company.

The candidate leaves feeling fairly assessed.

It is difficult to judge the capabilities of an individual within a small time frame. It is harder to do that in a way that feels fair and just. We try our best to accomplish this goal by tackling the idea from a number of sides. In order to talk about how a candidate is assessed, it is important to know what they are assessed for.

The traits that we are trying to assess are:

  1. How much emotional intelligence has the candidate acquired so far?
  2. What unique technical background and skills does the candidate bring?
  3. What part of programming does the candidate shine in?
  4. How much does the candidate know about Extreme Programming?

The first thing that happens is the candidate is given an explanation of the interview process. They are told what will happen, what they are evaluated on and why. It is important to eliminate surprise wherever possible. We believe this level of transparency is essential to the accomplishing our three goals.

Once the interview has been explained, there are a number of programming problems that the candidate is asked to work through. Each problem is straightforward with no obscure programming knowledge required. There are no riddles or surprises. Each exercise allows candidates to demonstrate a host of different skills as they work toward different solutions.

As they work through the problems, they have the opportunity to be given help and advice by three to four programmers that have been designated as their team. The team will not give solutions, instead they will help with programming language knowledge and design advice. The team will also rotate into the interview, giving the candidate a chance to navigate, teach, and guide various people with different skill sets.

There is a proctor, a person who takes lead on the interview. The proctor works as a guide for the candidate, helping keep them on target, and moving smoothly through each problem. It is the proctor’s responsibility to ensure the candidate understands what is happening throughout the interview.

Lastly, the candidate is not expected to solve the problems. In most cases it is not possible to finish in the allotted time. The purpose of the exercises is not the solution, but the path taken. We are not focused on what the candidate does not know, but rather the unique experiences and strengths the candidate brings forward.

We know if the candidate will be a good fit for the team.

There is a lot to consider and understand when talking about team fit. The Hunter Software Development Group works very differently than any place I have ever worked. We use a practice called “Mob Programming” to do all of our daily tasks. This means that all production code is written in a highly collaborative environment.

The factors that are key for our work environment are:

  1. Can the candidate communicate collaboratively?
  2. How does the candidate research new information?
  3. Do they demonstrate kindness, consideration, and respect?

Being part of a collaborative team is essential for anyone working in a Mob Programming format. Candidates will be asked explain how to solve problems and sometimes navigate a member of their team through the process of solving a problem. This means that one of their team sits at the keyboard and the candidate is asked to tell the teammate what to do. The disconnect from the keyboard forces some form of communication between the team and the candidate. Each of the team members is at a different skill level for different sets of skills. Inevitably, the candidates will either guide someone that is currently more skilled than they are or a teammate who is less skilled than they are. The way the candidate handles these two situations provides invaluable insight into that person’s communication style. It is important that the candidate shows kindness, consideration and respect during the whole process.

The processes of our everyday work environment puts highly collaborative teams into situations where they are acquiring new knowledge, usually as a result of having no foundational knowledge. The problems that the candidates are presented with are straightforward as for as core knowledge but ask questions that the candidate may not be familiar with. We look forward to web searches, text messages and anything else the candidate can use.

The candidate knows if the team/company is a good fit for them.

Letting someone know who you are is complicated process that can easily take the entire time of the interview. So how do you let someone know who you are within a couple of hours and still accomplish the other goals of the interview? This is one of the hardest questions we try to answer during our interview. We start by holding the interview in our open work environment. The candidate can just look around and see how other teams are working. They can hear the discussions, and see the excitement. A few feet away a team is working to solve problems and tackling goals.

Our interview process is part of our work. It is collaborative and social, designed to mimic the best parts of our work while still being an interview. Teammates take turns typing, helping, and guiding during the process, all of this helps give a feeling of what to expect.

If the candidate seems to be a good fit skill-wise, we then continue to a Lean Coffee session that lasts 45 minutes to an hour. This changes how the Q&A process for interviews goes as it starts by putting all questions and topics up front for all to see. Even if all topics are not discussed, the candidate and the team can see what was on each other’s mind.

A Lean Coffee format gives the candidate the chance in participating in the selection of questions and topics. Each person participating in the interview has three dots to vote on topics. These topics are then organized by number of votes. The topics with the most interest are then discussed first.

This gives the candidate a lot of agency in guiding the discussion. Their voice gets heard and they get a chance to have their questions addressed. It also allows them to focus on topics from the interviewer that they feel will make them sound better.

Each topic is given a five-minute window to be discussed. When the time is over, everyone votes on continuing or moving on. If even one person wishes to continue then the topic is continued, but only for two minutes. Then the voting cycle continues until everyone is done with the topic.

Each topic discussed is a topic not a question. Everyone is encouraged to reflect on the topic and address what it means for them. For instance, if the topic given by one of the interviewers is, “Describe a moment when you felt you really shined,” all members of the interview are encouraged to answer, not just the candidate.

This also means that topics brought up by the candidate will not only be addressed by the interviewers, but also by the candidate.

These discussions are the best way that we have found to truthfully let the candidate know who we are, what we do and why we do it.

In Summary

The Hunter Software Development Group has a very different approach to interviewing born out of a different perspective. We start with a foundation of kindness, consideration and respect and build from there.

We work to fairly assess the candidate based off of four types of skills. Emotional intelligence, unique experiences, what makes the candidate shine and what they know about Extreme Programming.

These methods have been very successful for us when hiring. We retrospect and adapt after every interview, so we are always improving. However, I would like to be part of a larger conversation. By discussing this with other professionals the community as a whole can gain insight from each other’s experiences that might not be seen any other way. Maybe the whole of the industry can improve and find yet to be discovered better ways. Mob Programming has led to better code quality. If we all huddle up and analyze how we interview who knows what will happen?

Toxicity is Abuse

Why I am writing this

This weekend I got into a lot of discussions about the responsibilities of a programmer.  I heard multiple times that a programmer cannot be held responsible if they are working in an environment that is toxic and forces bad behavior. While I do not advocate that someone threaten their ability to feed, clothe, or house themselves (or family) because of some theoretical responsibility, it is imperative to get out of a toxic environment.

This weekend I was in a conversation about a consultant that was described as abusive by the other employees and someone said: “They only fear for their jobs because they are too stupid to do the job right.” In other words, they deserved to be abused.

In another conversation, I mentioned that a programmer has a responsibility to do what is right. I was told that this was a pipe dream because of the toxicity of work environments. To me this translates as, “Offices can treat you any way they want because you are worthless.”

The funny thing is I have heard these statements before.

My mom married an advertising executive when I was 8. It turns out that he was a drug user who slowly revealed his nasty temper. I was often backhanded hard enough to knock me from my feet, and I got to watch as the same thing happened to my mom.

I heard the whispers of neighbors and even friends.

They sounded a lot like how I now hear people talk about toxic work environments. The words are slightly different but the meanings are the same. The fault lies on the victims. If they are being abused, then they deserve it.

It takes more courage, stamina and risk to stand up to an abusive person or organization than most people know. That chapter, in the end, was a small chapter of my life. My mom left that man one night and never looked back.

When we speak down on those being abused or make excuses for the abuse we make it even harder to do what is right. I implore you to stop this destructive behavior. Instead of making excuses for toxic companies, let’s do something about them.

Your responsibility

Every software developer has some professional responsibilities, even when we are unable to perform them. These responsibilities include:

  • We have a responsibility to produce bug free code.
  • We have a responsibility to produce code that is inexpensive to maintain.
  • We have a responsibility to produce value that is greater than our cost.
  • We have a responsibility to help those starting in the profession to be better at what they do.
  • We have a responsibility to share what we learn to progress the industry.
  • We have a responsibility to understand our customer’s, company’s or client’s business well enough to make informed business decisions about the software we write.
  • We have a responsibility to say ‘No’ to our employers if we are asked to do something that endangers time, profit, relations, information, reputation or money of an individual, company, community or ourselves.
  • We have a responsibility to provide value well above our cost.

 

Doing that will cost me my job!

If you are in an abusive relationship with your employer, one or more of those responsibilities become impossible to execute without being fired. That is a tough and scary place to be. I am not saying for you to risk your job, and risk being homeless.

What I am saying is that you do have a responsibility to leave. Don’t quit your job without a new one. Look for help within the community.

Then share what you learn. Help the community understand what you did to find a good place to work. This will give hope to those who are in similar situations.

We need to use economic power to stop abuse.

These abuses are not illegal. They are immoral, but that does not give us any legal ground to prevent them.

Companies need to make at least 3x their operating costs to be successful. That means that a company sees at least 3x profit from your pay. YOU ARE WORTH A LOT MORE THAN YOU ARE BEING PAID! We have value. In today’s economy custom software makes and breaks a company.

If a toxic company could not keep their employees or better yet not be able to hire then they will not be able to compete against non-toxic companies. The problem now is that programmers stay in toxic situations. This allows toxic companies to compete.

Let’s stop this. Leave those companies. Leave them as soon as you realize they are toxic. Abandon them, and move to companies that are doing it correctly.

Reinventing the User Group

User groups are awesome for technology. They accomplish several key goals. First, they give developers a place to learn the standards around their technology. They also give a forum for thought leaders to explain changes and improvements to the technology to those who care. User groups also provide an organized place to network with those within our same field. This is why they are so awesome.

User groups are an old institution, compared to anything else in the field. One of our local user groups has been around for 20 years. The idea of user groups has been around longer than that. Therefore, it is not surprising to see that the idea is being iterated on.

If you have not been to a user group, seriously- go. Let me explain the basic format. The members of the group gather to hear a speaker talk about some topic. The speaker gives a presentation and answers a few questions. Sometimes the group meets for an informal meal or drinks afterward.

I attend two user groups that completely break from this format. This break is not simply to be different, but because they have a different set of goals and they have found a format that enables those goals better.

The first group is the Technology Immersion Group (TIG). TIG’s goals are to give a forum for developers to take a topic and dive deeply into that topic. TIG is structured more like a large study group. There is a panel that functions as subject matter experts, and usually some study material used to guide the group. The panel spends a short amount of time introducing what was supposed to be covered in off-hours and most of the time is given to Q&A. If there is not much Q&A then the panel will explain points of what is coming next.

The second group is the San Diego Architecture Special Interest Group. This group’s purpose is to give a forum for senior developers and architects to discuss things they are encountering at work and get advice. This group’s format is a round table with three rounds. The first round is a problem round. Anyone in the group can ask the group for advice on things they are dealing with at work. The second round is a round table discussion about some specific technology. Sometimes they do a book discussion, sometimes a more open discussion. The last round is a show and tell round. You need to share something that you find interesting. This could be a tool, a programming language, a kick starter or anything. The last round facilitates discovery of things to either help us with what we do, or helps us unwind.

These two groups arose out of a need that was not being fulfilled by current user groups. That does not mean that current user groups are out-of-date, but only that there is space for new user groups to arise, particularly ones that fulfill the specific needs of their users. I hope to see more specialty groups that change the format in different ways. I also hope to see these two groups replicated in different towns. All of this grows our community and improves the industry.

You are a Star

I believe I suffered from Imposter Syndrome for most of my career, and if there is one thing I can say I have definitely learned is that you are the star. No matter your experience level, language, or technology bent; the fact that you are out there producing code makes you a star.

If you are not producing code: do so. I can promise you one sure thing: No code you write will ever be as bad as some of the code I have personally put into production. I wrote some things when I was a junior programmer that would make the faint of heart faint. Trust me, I had to run a production application in debug because a variable would lose its value. To keep the program working I would have to edit the memory location and then hit continue.

But that is the beauty of code. It is so valuable that even the worst written application, if it meets its basic need, will be profitable. The application above was so successful that the company’s competitors would hire us to do the work under their name.

Code is value. As long as you are producing code you are producing value.

Now I am in no way saying to stop learning, or searching for a better way. However, I am saying that you should go and produce. Build something, either for yourself or someone else. When you are done, build something else.

Searching for perfection will not help you discover that you belong. It will, in fact, do the opposite. Only by cutting your teeth on code will you begin to see the value you bring to the community.