Last weekend saw a thread on twitter blow up in the developer community. What could get such as reaction from a group of intelligent, creative souls? It was the thread below which highlighted that mythical creature, the 10x engineer and how to spot one. This was the original tweet series:
10x engineers
Founders if you ever come across this rare breed of engineers, grab them. If you have a 10x engineer as part of your first few engineers, you increase the odds of your startup success significantly.
When I read it I didn’t know whether to laugh or feel sorry for the author. I first suspected it was a ploy to gain attention for his fund, Accel.
First up, as proved here there is no such thing as a 10x engineer. The thread linked to above lists 11 points none of which make either a great developer or employee.
They may hate meetings. Most creative people struggle with meetings that add no value. They do see the value in a company or team meetings that set out their projects and address user feedback. Creative people want to be creating and getting validation. There is nothing special about hating meetings. I think it’s known as being “agile”.
They keep irregular hours and work when few people are around. When growing a company that is not 100% technical this is a major drawback. I worked (not managed) on a team where some contract developers worked when they liked. They would go missing for days, worked through the night and blocked progress on the application. No one could contact them. Feedback was rejected, it was a mess. That was on a project. If you are growing a startup you need alignment with the rest of the company to keep up the momentum. Flexible hours is one thing but this kind of employee will slow your team down. They may even become a negative force in your team.
They change their screen background to black and their i, f, and x keys are worn out. Sounds to me like they just installed Arch and copy and paste their code from Stackoverflow. In all seriousness, some developers just work with default settings and some configure their setups. We are all individual and I have a black coding background to prevent eye strain. I am not a 10x engineer!
They know every line of code that has gone into production. There is a couple of reasons this might be. They are the sole developer or they are a control freak. Either way, there is a big me in team situation going on here! It also explains why they can fix bugs so quickly. With that kind of knowledge comes great responsibility.
They are Fullstack engineers. This point doesn’t even make sense. There are a lot of developers that work across the stack out of choice or because they are a sole developer. He then says they rarely do UI work. Well then they are not fullstack, are they?
10x Engineers can convert thought into code and write it iteratively. That’s what we all do! In my experience developers “sketch out” code in two ways. They use TDD to help guide their design and thoughts or they write a 200 line method to get their idea out and then refactor it and write tests for it. Either way is acceptable. I have a developer who converts requirements into database design first and then it flows into code. Again, that’s fine. The remarks about developing idea’s in 4 to 6 hours fueled by coffee made me laugh. My TA took a problem from discussion to working prototype in 3 hours fueled only by Tea (he is from Yorkshire)
They don’t read the documentation and write code like English. No developer brought up since Google incorporated remembers the documentation for everything. Every developer Googles stuff and hits Stackoverflow. It’s normal especially when working with Reg Ex’s.
They are always learning new languages and frameworks. Any good developer will continue to self learn. Whether that is frameworks or libraries, it is one thing that most developers enjoy the most. They also appreciate that it’s key to staying relevant. They know what to focus on for their role or career and don’t try and learn everything. Knowing when to use new technology and not rewriting the businesses core application ever six months is the real skill.
10x engineers are poor teachers and interviewers. That is because they are frauds and lack any personal skills. Once a developer knows something they usually happily share it. It’s how StackOverflow works! Being a poor interviewer can be coached and anyone who has never done it before should be taught how to do interviews.
They don’t hack things. I think all real, committed, developers should be insulted by this. None of us hack anything. We all want to deliver good quality code that follows the agreed best practices.
10x Engineer rarely move companies or job hunt. When they move out it’s because you make their life miserable with process, meetings and other non-value-added activities. I am speechless. This is coming from an apparent VC. These are the very people that bring structure and processes to companies they invest in to add value and support their growth. This makes it sound like businesses should be grateful that the almighty developer has graced them with their presence. This comes across that these apparent wizards can only work on their terms at small companies. They are not team players.
As you can imagine some of the replies where angry. What made me smile was the developers that shared their insecurities and imposter syndrome fueled feelings. That’s the mark of a good developer. Someone open, honest and happy to discuss their skills, what they know and what they want to learn. I have worked with a vast number of developers across my career. No matter what type of business you are, you do not want to hire someone outlined in these Tweets. They do not add the mystical value they are rumoured to and will potentially damage you and your business.
I for one will be on the lookout for the qualities I mention above that I saw being shared in response to this Tweet. Engaged, eager, capable developers that are team players and aren’t perfect. That way we can all grow and learn together.
If you have any comments or thoughts around this post then please contact me via twitter or email.
Recently I reviewed some code that contained a problem that I hadn’t considered for a long time. Storing Html strings in a database.
The basic rule is that you should not store unencoded Html in the database for a couple of clear reasons:
Security. If the strings stored in the database are going to be inserted to the DOM or a <script> tag then it should be escaped. You should be following the security guidelines (as a minimum) from the OWASP Project. Doing so will help you prevent Cross-Site Scripting (XSS). Not encoding your Html (or XML/JSON) strings facilitates XSS.
It will break your pages layouts. Users have a knack for saving data you won’t have had the chance to think about or test. If a user creates a snippet in your database that includes </body> then you will get a broken page when it is rendered.
Most languages and stacks have inbuilt utilities and libraries for preventing XSS. They can handle the act of encoding so you do not have to write your implementation. In C# you can use the HtpUtility classes HtmlEncode and HtmlDecode methods. The sample code below shows how this works.
usingSystem;usingSystem.Web;publicclassProgram{publicstaticvoidMain(){varhtmlString=@"<!DOCTYPE html> <html> <head> <meta charset='UTF-8'> <title>Example HTML Encoding Page</title> </head> <body> <p>This Is An Example File</p></body> </html>";Console.WriteLine("Non Encoded\n{0}",htmlString);varencodedString=HttpUtility.HtmlEncode(htmlString);Console.WriteLine("Encoded\n{0}",encodedString);vardecodedString=HttpUtility.HtmlDecode(encodedString);Console.WriteLine("Dencoded\n{0}",decodedString);}}
In my projects, I tend to wrap the HttpUtility calls into extension methods. This means that if I have to change or add something to the implementation going forward I have one place to change.
In my last post, I covered why storing enumerations in your database was the wrong thing to do. The piece of work that came to me as a Pull Request that generated that post was a PR that kept giving. This post is based on a second issue I encountered in that review and why it is also the wrong thing to do.
In a database schema, a Foreign Key should only connect two tables.
The change in the PR was implementing an audit table for some notifications that are sent. The audit table was to store an Id for the sent notification, an Id for the Subscriber that viewed the notification and an Id for some content sent with the notification. All very simple. Only I could see that there was no Foreign Key defined for the SubscriberId Column. I tried to create a simple query to join to the subscriber’s table from the SuscriberId. It turned out that a subscriber table had not been created. Instead, the SubscriberId was either:
The Id for a fully signed up User (the projects user data is split between Customer and Supplier user data)
The Id for an Unknown Subscriber, someone that was not a customer but who could receive the notification.
I asked the original developer to write a query that would allow me to view the opened notification audit data. I did this to illustrate that following this approach of not using a Foreign Key would make for a very hard to maintain data schema. The reason they thought this was a good idea was that they are storing the SubscriberType which was an enumeration in the database. The query I was sent back was like the following:
Wow. So much confusion and hard work. I always have found that if I have a UNION in a query I have almost certainly got my schema or design wrong somewhere.
There was a clear need to clean this schema up. Remember
A foreign key is a column or group of columns in a relational database table that provides a link between data in two tables. It acts as a cross-reference between tables because it references the primary key of another table, thereby establishing a link between them.
By creating a Subscription table and accumulating known and unknown subscriber data we can then add a Foreign Key for the audit table. The table contains data specific to the subscriber and is now managed through the subscription process. While there are some duplicate data fields at present this is a temporary step until we clean up the customer and supplier data into a single user data table. At that point, we will remove the duplicate fields and use further Foreign Keys.
Thinking about your schema is vital as you develop your application. While you may find you adapt it as you build functionality, seeing clear relationships and dependencies is key to underpinning clean code. I have taken on projects in which the database has no Foreign Keys and they are always more difficult to maintain and enhance. You will benefit from not trying to save time in developing one feature as it will almost always make dependant changes or requirements harder to implement.
If you have any comments or thoughts around this post then please contact me via twitter or email.
SQL Server does not support Enumerated data types so please stop trying to force them into it.
Enumerations are used to declare a type that groups named constants. Most languages have them in a given form going as far back as Ada. In C# you declare an enumeration as follows:
publicenumColour{Red,Green,Blue,Yellow}
A common use for enumerations is to apply a label for grouped constant values. So the above may be written as:
publicenumColour{Red=1,Green=2,Blue=3,Yellow=4}
There are lots of articles on the wider web about using enumerations in your language. This post is about the misuse of enumerations which is not only bad design but has a major impact on your project.
Storing an enumeration value in the database may seem appealing. You define your Colour enumeration and define your entity class.
You define your SQL table column to be an int and add the scaffolding code to handle your crud operations. It all works and you move on.
Only a little while later someone else has to write a query on your table containing your Colour values. They have no idea what the values represent. Is 1 red or green or blue? Who knows. They start the process of tracking down who wrote the code. Soon they arrive at your desk but it is 4 months since you last looked at the Colour code. So you have to open the code and find the enumeration declaration and provide them with the details. Now they have the details they end up with a nasty CASE block in their query like
CASEWHENColour=1THEN'Red'ENDASColour
Removing magic numbers in our code by using enumerations, we have complicated the data schema. The better approach is to use a lookup table in your database. We then create a relationship via a Foreign Key with the table that stores our Colour data. Again there are plenty of articles on defining database tables and relationships. The point of this post is to show that storing enumeration values in the database is wrong. It leads to a confusing data schema and difficult to maintain code. Using a well-defined database schema will result with an extra Colour type in your code and an easy to follow validated dataset that is built on a standard join.
This article has made enumerations sound like they shouldn’t be used and that’s not that case at all. In a future post I will cover how and when to use them effectively.
If you have any thoughts around this post then please contact me via twitter or email.
I have asked my team, juniors through to seniors I have worked with for over 10 years, to each write a full review, on me.
Why? Well, I undertake reviews of each of my team every three months. I have written before that this is a useful technique when running remote teams. It ensures that issues do not get to brew for too long and I can hear what’s going well and what needs improving. It also means that the team get quality one on one time with me. The reviews are simply an informal chat. We can cover anything from particular work to development techniques and training plans. I make the effort to write up the conversations and the employee gets to comment and sign them off. We can then review progress on each next review.
During reflection on the first half of the year and how its been going it occurred to me that those reviews are generally one way. I gave thought to why this was the case and how much impact doing the reviews via video chat can have. Does my team have feedback that they would not be comfortable to share in person? Does the time limit we try to stick to mean that we never get to 180-degree feedback? Have I just never asked the questions?
So I have sent the whole team a blank review form. What should I be doing? What have I done well and not done well? What should I think about focusing on? They can write as much as they like and I have made it clear that the aim is to give me direction. There is no comeback and if they don’t want to discuss points with me they don’t have to.
They have two weeks to complete them and send them back. I will follow up in a few weeks time on the results and if it was a useful exercise.
To be honest, I have never felt quite so exposed.
If you have any comments around this post then please contact me via twitter or email.
Welcome to my site and blog. You can find out about me and read my thoughts on code and technology, start-ups and building things.
