Raw UDP+checksum might have been even better. Easier to build on a tiny microcontroller. Lighter on the network. Offers an expansion path to NAT hole punching for push updates.
The Number One Trait of a Great Developer
31–40 of 122 posts
Re: The Number One Trait of a Great Developer
#32Not too sure about the specific content, but that blog theme is beautiful. I wish there was a collection of more text-based web designs.
It uses BigText (https://github.com/zachleat/BigText) to make each line of text to fit the container width
Re: The Number One Trait of a Great Developer
#33The catch-22, of course, is that at some point, MySQL was the "new thing" to Diane, so how did she learn it in the first place?
The answer of course is that judgement is less about making decisions upon familiarity per se and more about knowing when unfamiliar technology seems to provide good trade offs given what is known about it. For example, PostgreSQL may be unfamiliar, but choosing it is a wildly different type of decision than choosing another less mature unfamiliar data store, since at a high level PostgreSQL is known to be a well-understood, mature technology that may provide significant leverage over MySQL in certain scenarios. Being able to understand the various dimensions of technology choices and make good ones with limited information and experience is what makes good judgement, not just an outright aversion to unfamiliar things.
Re: The Number One Trait of a Great Developer
#34I don't agree with the article at all. At least, not in the way it was presented.
Sure, designing such a small system to use Cassandra and Protocol Buffers might be overkill. Then again, it might not. Without more information, it would be impossible to know which one is the best developer.
For instance: how much time did the Node+Cassandra+Protobuf implementation take? How is that, compared to the junior dev that only knows MySQL? Was Jack on a deadline, or did he have time to explore alternatives? Was Jack really inexperienced, or he did have experience in the new tech, but wanted those in his resumé?
Were they billing hours? What about the coworkers, do they only know Ruby and MySQL too, or are they confortable about learning new things? Do they even have coworkers?
Was Jack's solution modular enough that components could be replaced, if they were a problem? (Cassandra, for instance)
And most importantly: what was it that made Jack's implementation unmaintainable? Sure it wasn't because they are "new"(the article is rather old) technologies. Was the code badly documented? Was the design flawed?
Jack's biggest flaws, as can be inferred from the article, is not asking enough questions before diving into the implementation, and not getting permission before using "new" tech.
I know the author did not get in depth about the personalities or the project itself because he wanted stereotypes to illustrate a point, which was taken. But the problem with it is that other people could get the impression that "new" technologies should never be considered, or that any attempt to make the application "scalable" from the beginning is a "Jack trait" and thus, wrong.
Not to mention that Jack might even be right, should the company's expectations prove to be too low.
Re: The Number One Trait of a Great Developer
#35Dianne's solution creates a maintenance problem if the number of devices grows too much or if network stability is a problem, or if there is an expectation down the line of, for instance, push sync. My point is not that her solution was not valuable, but that to suggest that the maintainability of the two solutions is black and white like this is wrongheaded. The really unfortunate implication here is that learning n…
> Dianne's solution creates a maintenance problem if the number of devices grows too much or if network stability is a problem, or if there is an expectation down the line of, for instance, push sync.
None of those are maintenance problems, they weren't part of the additional spec. For custom to-spec development, if the requirements change then it's expected that the code will have to change as well, incurring a change order.
A maintenance problem would be something like MySQL being an unreliable DB or the code she wrote being unreadable. If someone needs to go in and fix inevitable bugs then there will be issues.
If the customer wants to add features later then they'll have to pay for the changes and if the new features are different enough from the original spec then the changes might be quite expensive.
Re: The Number One Trait of a Great Developer
#36Dianne's solution creates a maintenance problem if the number of devices grows too much or if network stability is a problem, or if there is an expectation down the line of, for instance, push sync. My point is not that her solution was not valuable, but that to suggest that the maintainability of the two solutions is black and white like this is wrongheaded. The really unfortunate implication here is that learning n…
I agree with the op but have a different spin on it. It depends on what you see as your core business. Is your business about the technologies used to build the application or are you using technology to let, "kitchen devices synchronize their list of recipes". If your business is the later then you are better of using tried and tested technologies your developers are familiar with and can maintain without detracting from the core business.
Edit: grammar
Re: The Number One Trait of a Great Developer
#37This is a problem because writing working, maintainable code that solves the given problem rather than an imagined problem should be the trait of a competent developer. I had the pleasure of going on a course run by a German developer recently, and his brutal focus on quality and maintainability made me rethink what we class as a good developer. Brutally in the article Jack is not a rockstar - Jack is incompetent. A…
Maybe we should be asking why the things we make need to be maintainable. Why can't I just make program module x to input a and output b and never touch it again.
I believe modular code is the future and the sooner we get there the better.
Re: The Number One Trait of a Great Developer
#38Dianne's solution creates a maintenance problem if the number of devices grows too much or if network stability is a problem, or if there is an expectation down the line of, for instance, push sync. My point is not that her solution was not valuable, but that to suggest that the maintainability of the two solutions is black and white like this is wrongheaded. The really unfortunate implication here is that learning n…
The ideal way is to build for either postgres or mysql, using vanilla SQL, therefore both shipping something that is known to work (mysql, in her case) and learning something about postgres. My observation is aside from anecdotes and peculiar corner cases which should be very strongly avoided, the philosophy of mysql is always the cub scout motto "try your best". The philosophy of postgres is more like "It shall be perfection at all times or I will curl up and die horribly as the ultimate prima donna". When times are good and there's nothing unusual, there is absolutely no practical difference. Its a meaningless personality test to walk up to a dev and ask which outlook on life matches their own outlook and which makes them feel like vomiting. It tells you something about the dev and nothing about the problem. Rarely, if ever, does actual business need enter into the debate.
Postgres/mysql is a business needs decision that needs to be made at a higher pay grade than hers, most likely. Assuming anyone at a higher paygrade knows anything about databases or specifically mysql vs postgres. If no one at a higher level understands, its her job to put it into simple little one syllable words even an overpaid MBA can understand, or they simply have to trust an underling to make a higher level decision.
Something not discussed in the article specifically is this behavior comparison is classic bodger/tinkerer behavior aka Jack vs true engineer behavior aka Dianne. Most people are flexible between the two, some are notoriously inflexible... I have a backyard garden swing built to hold 4500 pounds because that reflected my junk pile at the time and desire to never maintain the swing after installation, although over-specification behavior like that at work would lead to my firing or the financial failure of the company, so I gotta know when to switch. This should have been explicitly discussed in the article.
Re: The Number One Trait of a Great Developer
#39No, that's the number one trait of a great employee - and the sign of a leader. The number one trait of a great developer is literally their ability to quickly write amazingly elegant code and manage complexity.
No, that's the number one trait of a great employee - and the sign of a leader. Exercising self-control is being the leader of one person.
You're right. I meant to say one of the signs of a leader, you also need charisma && (authority || prestige).
Re: The Number One Trait of a Great Developer
#40Dianne's solution creates a maintenance problem if the number of devices grows too much or if network stability is a problem, or if there is an expectation down the line of, for instance, push sync. My point is not that her solution was not valuable, but that to suggest that the maintainability of the two solutions is black and white like this is wrongheaded. The really unfortunate implication here is that learning n…
There's a difference between technology and implementation though. If Dianne had chosen a solution that fundamentally can't scale easily then that is a poor decision, whereas a technology that can scale written in a way that can be upgraded later is much more flexible. As for the MySQL v Postgre I see that as a sensible Agile decision - much more confidence in quality now, with the knowledge that in the future a move…
The REST/Sinatra/MySQL solution was chosen in contrast to protocol buffers and Cassandra - the scaling potential of the systems are very different.
If you haven't worked on a project of this nature then the complications are likely not to be obvious to you. For instance, once this ships, they will be required to maintain that version of the REST API that was designed forever, including any side effects or semantic weirdness. If they determine that some changes are required for the sake of scale, they need to cross their fingers pretty hard that they can squeeze all of those changes into the existing API.
If this system were truly designed with Dianne's current abilities in mind, we don't know what that REST API looks like. Is it possible to imagine that it sends the full listing of recipes on every request? Absolutely. Are you going to be required to do that forever once the device ships? Yes.