I never quite worked out what "rockstar" meant, but surely choosing new tech for the sake of it isn't it.
I don't think it involves wearing leather pants to work, although it doesn't exclude it, I suppose.
51–60 of 122 posts
I never quite worked out what "rockstar" meant, but surely choosing new tech for the sake of it isn't it.
I don't think it involves wearing leather pants to work, although it doesn't exclude it, I suppose.
Why was -- in this contrived scenario -- Jack's solution a "maintenance nightmare"? Just because.
The 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…
I think that asking why a programmer knows any piece of knowledge is a very good glimpse into how competent she is. I don't care that somebody likes Git more than SVN but I do care why (on a technical level) somebody likes Git more than SVN.
Earlier quoted context omitted.
> 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 chan…
The ideal solution would be somewhere between a massively scalable system and a system that just barely meets expected capacity. When an engineer is designing a bridge they over-build just enough that the bridge is solid even when packed with 18 wheelers in a snow storm. Most of the time the bridge won't be anywhere near that load. A great developer builds to the expected capacity + some additional capacity based on…
It may be more appropriate to properly separate concerns and build a flexible architecture that can be upgraded over time to meet needs as they come, or left as-is if those needs never manifest.
This 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.
What you said is akin to saying: "sure, the code we wrote is slow, but we can fix this with hardware in a month - Moore's Law!". That doesn't help anyone - it's just wishful thinking.
Apply a bit of brain power and make your code simple and straight forward so that your customer doesn't waste time and effort maintaining it (or more likely in the "Rockstar" case, replacing it entirely).
The 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…
Diane most likely chose MySQL because it was the most popular open-source database. Popularity is often reason enough to choose a particular tool, because it means that that tool is more likely to be supported by other good tools.
Widely available, many eyes searching for (and patching) security bugs, many people can understand and debug it, probably the most documentation out there, its the simplest possible overall way to do it, she's not exactly doing anything new, so using a tried and true successful solution is good business and sound engineering practice.
So, the cub scouts are building birdhouses this year, again. Last year we used hammers. I found a nailgun recently invented in the black forest region of Germany which shoots a special birdhouse domain-specific-nail thats a precise metric size specialized for this kind of wood and building birdhouses, unlike local nailguns which use an air compressor or .22 blanks, this one uses compressed unicorn gas, which everyone who's cool knows it doesn't smell, and its brand new and I'm the only guy this side of the pond who knows anything about this new nailgun and the only guy who can use it or maintain it, and it cuts hammering time down from 5 minutes per birdhouse to 5 milliseconds even though theres no business case to care. Oh no wait I'll just bring some hammers again this year. But old fashioned obsolete hammers don't scale to 10B units! Oh that's OK the school gym where we have pack meetings only holds 500 and usually only about 20 scouts show up anyway and the countries population is only 400M, so I'm all good. And given other business constraints the scout pack is permanently constrained to grow slower than I can buy more hammers. Yeah, looks like a job for a hammer, its hammer time... Would I roof a house with a hammer, well no, but I'm not roofing a house so I don't much care.
The 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…
1st dimension: power of the tool
2nd dimension: ecosystem of the tool (developers/libraries/support/etc)
3rd dimension: developer's ability to use the tool (time to learn, current ability, etc)
If you think on factors going from 0 to 10, MySql could be [4, 7, 8] and Postgres could be [7, 7, 4] for that developer.
Of course the 3rd factor depends on the developer (and on the time available), for example I know Go is very powerful, but I wouldn't use it, unless the available options for me are not good enough for a given problem (so the time to learn compensates for the loss that using other technologies would incur)
This 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.
What this article is really arguing against are early-adopter developers who chase every new fad for its own sake and prioritize their own amusement over the best solution at hand. But this says about how good the developer is, only how good their actual contribution to your company will be relative to their potential. A shit developer can do their best but it still won't measure up to a great developer's trend-chasing effort.
Now even assuming some base level of competence, there are many different mindsets and personalities that lend themselves to different types of programming. I could go on and on about specific skills but we're mostly programmers here so I'll just hint at it: debugging skills, low-level skills, architecture skills, analyst (business requirements) skills, hci skills, modeling skills, clairvoyance, luck. All of these things have varying degrees of importance depending on the job and team at hand, and some combination of them will make someone the best developer for some specific job.
But if you find my answer too wishy-washy and you want specifics about what makes a great developer I'll boil it down to two things. First, to achieve competence as a developer, one needs have the tenacity and logical thinking to debug any issue no matter how arcane. Second, to achieve greatness one needs to be able to comprehend the entire problem space in such a way as to account for many more factors than an average developer let alone a non-technical person could ever hold in their head at once, and have the ability to translate those constraints into a system which is at once easier to understand and more elegant than the vast majority of competing solutions.