A Developer’s Sixth Sense

Most engineers are fact driven by nature. Which is a good thing. I am here to argue that listening to your intuition does serve a purpose and can help you become a better developer…or anything for that matter. We don’t always have all the facts. The best people know how to use their instincts to their advantage. This is something I have been working on over the last year and I still have much room to grow.

Below are 4 areas of software engineering where intuition can help.

1. Task Scoping

You are given a piece of work and told how long it will take. Do you get a “shit…I can’t waste a single second” feeling? Or just a “this is going to be tight”. We can’t as developers be expected to remember how everything works. There will always be times when we forget about a particular use case, which inevitably blows an estimate up. But our gut (or unconscious mind), does surprisingly well at alerting us.

Try to recognize that feeling and ask yourself why you feel that way. Was it because the last time you refactored that class it ended up being a tangled mess? Or was it because the last time you built a component that interacted with components A and B it took much longer than expected. If it makes you anxious or pressured, the task is probably under scoped.

When estimating, listening to your gut can help you surface problems sooner rather than later. Which is what all engineers should strive for – and project managers love! The key is to recognize those feelings.

2. Code Reviews

Code reviews are where I use my intuition the most. At Thinknear, we code review everything and using this sixth sense helps speed up the process for me. Once you start doing code reviews regularly you start to spot “code smells” faster. But many times I will look at a piece of code and say “that looks wrong” or “something here doesn’t look right”. I might not know how to fix it or what is exactly wrong, but my gut has served its purpose – identifying a potential issue.

Some examples of things that I tend to pick up on are:

  • Am I having a hard time reading the code? (better method/variable names?)
  • Why is this method so long? (too many things happening in method)
  • Why are there so many unrelated methods (too many responsibilities of the class)

Those are just a few to give you an idea. Once you found a problematic area, you can move to suggesting fixes.

3. Architecting Solutions

We at Thinknear, collaborate on all major architecture designs. Usually a single engineer is responsible for figuring out the design. But that person is responsible for running the solution by at least one more engineer. I can’t tell you the number of times I came up with a solution and then had a better alternative or alteration suggested by one of my peers.

Intuition also helps in these discussions. This is the place where we all probably use it the most. Someone explains a design that makes us go “eeek!” inside. We explain why it might not be the best idea. But what about those situations where you can’t quite put your finger on it?

Still bring it up.

Many time just bringing up the fact that something feels off, will jog someone’s memory. “Oh yeah, I remember when we created component X we did that and we had to re-write it”. Contrast that queazy feeling with the feeling of “wow that design is slick”. That can help you recognize when you should be pushing back. Or what about that “there is got to be a better way feeling”? Listen to yourself. Bring it up. Give yourself credit for the knowledge you have amassed.

4. Interviews

Your unconscious mind processes a ton of visual cues. And it only brings things to your attention what it thinks you need. Its really amazing. We’ve all heard about the experiments done with dinosaurs walking across television screens while the onlookers were distracted with something else on the screen.

Culture fit is one of the most important factors in hiring a candidate. Yet its hard to gather empirical evidence on how someone might fit in. With such a limited timeframe to evaluate someone, on something so important, it can be difficult. At Thinknear, we always have lunch with the candidate for them to meet the team in a more informal setting. It also gives the candidate time to assess who we are. Yet intuition should be used as another data point in these scenarios.

This is one area I have tried to improve on the most. I have interviewed over 150 people for sure and I can speak from experience that your intuition only gets better with experience when evaluating people. From my experience, gut feeling is grounds for turning down a candidate, but not for accepting a candidate. It can be a useful tool, one of many you should be using when hiring your next co-worker.

Those are the four areas I have seen that intuition helps in improving my work. Sometimes you don’t have all the facts. Use your gut to your advantage. It is a great ally.


One-off Webpages That Make Life Easier

Below is a list of one-off webpages that are extremely useful in my day-to-day life as a developer. I’d love to hear what other pages I am missing out on or if you have better versions of any of these tools.

1. JSON Beautifierhttp://jsonviewer.stack.hu

Simple and clean UI. Handles broken/incomplete JSON very well.

2. Convert Java Date to Millis:  http://www.fileformat.info/tip/java/date2millis.htm

Converts both ways. Nothing special. When I don’t want to load Eclipse.

3. Amazon EC2 Instance Comparisonhttp://www.ec2instances.info

Not sure how Amazon doesn’t have something like this. Chart form. Easy to compare. Keeps up to date as best as I can tell.

4. Ruby Regex Testerhttp://www.rubular.com

Clean UI. Legend at bottom. Able to easy test many inputs.

5. Git Cheatsheethttp://cheat.errtheblog.com/s/git

Commonly used commands with descriptions.

6. AWS Service Health Dashboardhttp://status.aws.amazon.com

Quickly see if a service you depend on is having trouble.

7. AWS Service Pricinghttp://www.cloudomix.com/pricing

Cost of all services and comparison. A lot of information.

8. Apache Hive Functions:  https://cwiki.apache.org/confluence/display/Hive/LanguageManual+UDF

List of all built-in functions with descriptions.

9. TCP Variables:https://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/tcpvariables.html

Simple list with descriptions all in one place.

10. Find Ruby Gemshttps://www.ruby-toolbox.com

Quick way to find and compare gems with same purposes.

11. IP Address Lookuphttp://www.maxmind.com/en/geoip_demo

Most reliable and matches most accurately.

12. Colour Palette Searchhttp://www.colourlovers.com/palettes/search

User generated palettes that you can search by color.

13. Online Diagram Creatorhttps://www.draw.io

Great for architecture diagrams.

14. Nerd jokeshttp://devopsreactions.tumblr.com/archive

When you are having a bad day.

That’s all I have. These help me tremendously through my work day and help make my life more productive. What are yours?

Discuss on Hacker News.

Everyone will be a programmer one day

We are currently in the first evolution of computer programming.  But we are seeing the beginnings of the second.  The first evolution was based on humans learning to program. Many industries have been revolutionized by technology, many more than once.  But there are still many to go.  Part of the problem is that people in technology are not as heterogeneous as society and that leaves gaps in knowledge.  Over time those gaps grow smaller but it can take awhile.  Being able to program is powerful because it allows you to build solutions for yourself.  Every industry has problems which can be solved or improved by software.

When I was coaching/playing for the MIT Graduate Men’s soccer team I got to meet a lot of really bright people who had the opportunity to travel, study and innovate in important industries.  Many of the post grad students, especially in the science field, had learned to program out of necessity.  Their main response was similar to, “i am so much more productive and/or thorough with my work”.  Most of these guys had learned it very late in their academic career, but I realized that this type of training will make it into many more career tracks.  Steve Jobs once said in an interview that he believed everyone should learn to program.  He believed that programming should be a required skill to learn in school.

Everyone will not become a programmer.  But I believe many more people will have the ability and access to program.  There are many examples today and it is trending upward.  There are high level language frameworks being created to allow non-programmers to program systems.  Services like CodeSchool are enjoying a big bump in traffic from people wanting to learn to program.  It should become a core class in high schools if it hasn’t begun already.  Programming is a versatile tool.  It is not like a mathematical formula that you learn and apply in certain situations.  It is not a war that you learn about and recount later.

Programming is a tool to solve problems.

Don’t get me wrong.  Programming well is hard.  Especially when you are trying to architect large systems.  But in many circumstances that is not needed.  Small programs for repetitive tasks or calculations don’t need much design.  But they can be extremely useful.  Once people in various industries start to learn programming early in their careers, that is when we will see another step function in change in those industries.  The best problems to solve are the ones you have yourself.

Technology has always been about revolutionizing industries.  Many industries come later than others and some have been changed more than once already.  Once we can arm everyone with the proper tools to solve their own problems, is when we will see another large return on investment into programming.

Discuss on Hacker News.