Jack drops a couple turds into your codebase, but so does Diane. Hers just take longer to arrive. Inability to seek actual best tools based upon personal fear of the unknown does not a great developer make. Basing one's code off the familar or the purported "best practice" without actual knowledge leads to drek down the road. A great developer chooses the right tools for the task (along with other things...) Diane's,…
The Number One Trait of a Great Developer
111–120 of 122 posts
Re: The Number One Trait of a Great Developer
#1121) What sort of load will this system need to handle now and in the foreseeable future, and what sort of latency can it tolerate? How will that load flow through the system? In this contrived scenario, the server and database need to be able to handle an average throughput ~9 requests a minute with lax latency requirements (it's okay if things are backed up by a couple minutes). The devices only need to handle one operation per hour. Planning a safety margin of perhaps 10-100% above that is prudent; more than that is premature.
2) What are the upgrade characteristics of each component: how will you upgrade or replace each component? how long would it take? can you even upgrade them? Some parts will be in a central location, and can be easily upgraded with only minor downtime. Some will be deployed on hardware you don't control or otherwise can't be easily upgraded. In the worst case, they're embedded in firmware and you need to support them as-is for their entire lifespan.
3) What are the failure modes of each component: what could cause them to fail? how likely is that? what will happen if (when) they do? how will you recover?
The answers to those questions determine how much risk you can take when designing each component.
Also, look at where the answers are different for two components that talk to each other. Any time there's a boundary between two components that can't be upgraded at the same time, or where one component talks to another with different failure modes, there's an interface. You need to think hard about the interface between them: how will they communicate? how will you extend that communication protocol over time while maintaining backwards compatibility? how will they behave if the other has failed? Those interfaces are locations where over-engineering a bit can pay off.
So for this example, I would think hard about what runs on the devices and how they talk to the back end, because that code is probably very difficult to upgrade. I would use rock-solid, dependable technologies for those. Similarly, the database probably stores important information, and one of its failure modes is that all the data is lost due to hardware failure. So I would use a mature database there, either MySQL or PostgreSQL.
But the back-end service? It's easy to upgrade and because it's stateless, its two failure modes are that it crashes and it needs to be restarted, or that the hardware fails and it needs to be re-deployed. Neither failure mode is that bothersome, so it doesn't matter what technology you use there. Use whatever the team is most familiar with and will let you iterate the fastest.
Re: The Number One Trait of a Great Developer
#113It seems silly and obvious to say that, but many engineers seem to have forgotten that goal.
The 2 mistakes I see over and over are systems that are optimized for Novelty and systems that suffer from Neglect.
## Mistake: Optimizing for Novelty
Bored engineers often optimize for novelty. That means they add technologies to your systems not because they're needed, but because the engineers want to play with them. Rather than consider the implications of making the systems more complex and more costly to manage, they are easily lured by shiny new technology and come up with justifications to use it even if it provides negative business value.
These engineers aren't bad people. They will legitimately think that the new technology is a good idea. They may even make an impassioned business case for it. But listening to these engineers is the equivalent of a naive young girl believing a teenage boy "really loves her" at the end of a first date when he wants to go to Make-Out Point "just to talk". The boy may actually believe this in his heart, but any woman with more experience will see exactly what's really going on.
To see companies that suffer from this, it's as simple as looking at a few job postings for developers. Look for the postings that list requirements for waaaay more technologies than the company could possibly need. It's a sign that novelty has cursed that company.
For more on this, see my post: http://devopsu.com/blog/boring-systems-build-badass-business...
If someone offers to make your systems "exciting and cool!", be very afraid. Your systems are the foundation of your business and they should be simple, secure, scalable, and generally pretty boring.
## Mistake: Neglect
The other problem I see frequently are systems that are simply neglected.
No one knows if the database backups work. No one knows if there are critical security updates that need to be applied. No one knows if the site is down until a customer complains. No one knows if the guy who quit a year ago still has a copy of the production database. On and on...
You will often see neglect in systems that became complex due to novelty. Every new technology that is added to a system requires monitoring, documentation, and security updates. The more technologies that get added to a system means the more technologies that are at risk of becoming orphans and neglected.
## Shameless Plug
Manage servers? One of the biggest wins against neglect is to use a configuration management tool like Ansible, Salt, Chef, or Puppet.
If you want to make sure your systems are fast, scalable, and secure, the first step is having full control and power over them.
Tomorrow, Sept 4th, I'm launching my book "Taste Test: Puppet, Chef, Salt, Ansible" which is designed to save you the days or weeks of research when picking one of these tools.
In the book, I implement an identical project with each tool so you can see what each one is like to work with. You may be surprised at which ones were super easy and which ones were really difficult to work with.
To get a discount for the book release, just sign up on the mailing list: http://devopsu.com/books/taste-test-puppet-chef-salt-stack-a...
Re: The Number One Trait of a Great Developer
#114This is one of those "why I am a great developer" sorts of posts that allows people to pat themselves on the back and congratulate each other on how great they are, passive-aggressively sending it out to the team in hopes of denigrating some team member who likes newer things. In this case "judgement" means "uses the things that I know", and there seems to be little evaluation beyond that high-level use case. Why was…
> Why was -- in this contrived scenario -- Jack's solution a "maintenance nightmare"? Just because. Maybe this article will shed some light: http://www.xaprb.com/blog/2010/05/10/the-manager-programmer-...
Re: The Number One Trait of a Great Developer
#115This is one of those "why I am a great developer" sorts of posts that allows people to pat themselves on the back and congratulate each other on how great they are, passive-aggressively sending it out to the team in hopes of denigrating some team member who likes newer things. In this case "judgement" means "uses the things that I know", and there seems to be little evaluation beyond that high-level use case. Why was…
Re: The Number One Trait of a Great Developer
#116Earlier quoted context omitted.
But if I had to take over a project from someone, to maintain it, I'd MUCH RATHER have it be done using those technologies than MySQL and Sinatra. Yikes! Except that isn't really an option in most cases. The two most realistic choices are: Take over a high-quality implementation using somewhat stale tools or an average to shoddy implementation with newer tools that the developer was learning on the fly.
Take over a high-quality implementation using somewhat stale tools or an average to shoddy implementation with newer tools that the developer was learning on the fly My experience has been that developers who are most interested in innovations in this industry are dramatically more likely to build better solutions -- the passion and interest cuts both ways. Versus the career developer who does the absolute minimum ne…
Re: The Number One Trait of a Great Developer
#117Jack drops a couple turds into your codebase, but so does Diane. Hers just take longer to arrive. Inability to seek actual best tools based upon personal fear of the unknown does not a great developer make. Basing one's code off the familar or the purported "best practice" without actual knowledge leads to drek down the road. A great developer chooses the right tools for the task (along with other things...) Diane's,…
I would also factor in the ability to understand the requirements. In this case, knowing where the module is running - the server side.
Possibly being able to write a very clear requirements/spec with very few words is one of the hallmarks of the greats. (The initial RFCs for TCP/IP are amazing).
Re: The Number One Trait of a Great Developer
#118Re: The Number One Trait of a Great Developer
#119Re: The Number One Trait of a Great Developer
#120This is one of those "why I am a great developer" sorts of posts that allows people to pat themselves on the back and congratulate each other on how great they are, passive-aggressively sending it out to the team in hopes of denigrating some team member who likes newer things. In this case "judgement" means "uses the things that I know", and there seems to be little evaluation beyond that high-level use case. Why was…
From a management perspective, it is easier to hire competent new employees for established, popular technologies. Employees don't stay around for long anymore, especially dynamic, innovative employees who stay up to date on the newest technologies. People like that get recruited away all the time. Then who's going to maintain your bleeding-edge system? How long will it take to hire another employee of the same calib…