"It does not matter how many people use framework X."
Unfortunately, it does. It sort of makes sense Manifest Against Mediocracy includes such statement, since this is the large impediment in fight against mediocracy, but simply asserting it doesn't make it true.
It was not simply asserted. It was supported with an example of a security problem that would be experienced by everyone using a framework. We've seen it in reality, with the left-pad fiasco.
Many people got into extreme and even used stuff like left-pad.
I try to only include third party software for stuff I don't have the time or skills to implement. This makes my utils directory a bit bigger, but that's it.
> Therefore, our true purpose is to express the intentions of our clients using as little code as reasonably possible, accompanied with lots of documentation and lots of tests (testing code and unit tests don't count as LOC).
Software Engineering is an exercise in compromise. How does the risk of a bug compare with the benefits of the code?
I think it's fair to say that there is more code being written today, by a more diverse group of people, than ever before. It would be a real shame to tell them the amount of code they should be writing is 0 since that's the only way to prevent bugs.
These lines sound like a recipe for scope/feature creep and never ending development process.
>Never do requirement analysis. Never write technical requirements or functional ones. If you do, you have already failed.
In that case, how do you know when the software is finished and your contract has been fulfilled?
>Creative solutions are often holistic in nature, driven by first-hand experience, discussion, interaction and... thinking. If you want a developer to write a great piece of code, let him or her scratch the itch you're trying to scratch.
So, you do all your thinking, without capturing anything, and then the software is finished when the developer is bored?
These may make sense in a Utopian existence where profit means nothing. However in the real world, projects are driven by requirements, and the developer that can fill these requirements the fastest is the developer that will prosper the greatest.
Theres 'building castle from our minds' developing and then there's 'get shit done' developing.
I'm kind of sick of so many devs fighting to try and outsmart each other. I'm looking at legacy code basses where people wanted to have a go at a technology and it just became an unmanageable abortion because they move on, support picks up the gig and then rot. Now I'm learning obscure technologies not in use by the majority of the bell curve because someone had a thought bubble. -- end rant.
I'm all for the middle ground. Money flows to those who deliver.
Tbh I know what he is saying. Software that is speced up by BA's and driven by their requirements tends to end up being really bad software.
The best software is built up over time as demand arises for those features. Create the feature requests as they are required and implement the requests.
I think one of the major causes of why this type of thinking ends up building bad software is that BAs include literally every corner case they can think of. Ends up being extremely complicated right from the start. Then they miss other requirements. If you build by evolving software from a simple beginning just to scratch an itch, you learn the true requirements from experience. Learning about the optimal architecture from experience as they go.
Hard to do when your working off a software dev contract. Fairly easy to do if your building a product.
Sounds like the flaw is having business analysts do the requirements analysis instead of systems engineers. It also assumes you are creating a standalone application and not a piece of a larger system.
Never mind that thoughtfulness of design is a requirement to understanding complex distributed systems. And before we go off saying that few developers need to know how to program distributed systems consider that even a modern processor is a tiny distributed system.
This idea that genius will spout forth from the hands of the programmer in the spur of the moment is hogwash. If you believe this then let's make a wager. We'll pick a simple, standard algorithm. I'll give you the requirements, you implement it. I'll model your solution and run it in a model checker. I bet you that the checker will find an error in your implementation. Simple, right?
A colleague of mine did this to his students. They had to implement binary search. The majority of their solutions had bugs. These weren't under-grads.
Programming is hard because thinking is hard and we deserve the best tools we can find to help us think clearly and precisely. In the real-world we can always just add a fudge-factor to make up for our uncertainty while computers are infuriatingly discrete systems.
This flow of "thinking in code," is simple-minded ignorance. Think in code all you want. You won't be able to solve the hard problems that way. You'll just write sloppy code.
you missed the point: The point is, if the requirements for a piece of code are so complex that you NEED to write a requirement analysis, that you NEED to do anything other than plan out your code, and write it, than your software is already too complicated. You need to narrow the scope. Lots of small systems is better than one large system.
There are domains wherein the software is inherently this complex and requirements analysis is unavoidable. This is particularly true when decomposing one large system into small systems. Someone needs to be the systems engineer that determines how the pieces couple together and how overall system functionality is divided into the pieces.
Requirements analysis is also critical when the software is coupled to particular hardware or a particular process.
I disagree. Complexity can arise through interactions between simple pieces of software. Given, planning that out may be complex, but certainly less complex than writing it all in one go.
All you're doing is shifting complexity around. Don't want one big piece of complex software? Fine. Break it up - now you have a bunch of simple pieces of software that all need to work together in a complex manner. You still need to plan for how all that works, and that often requires complex requirements.
It's not "certainly less complex". The total complexity of the system is still the same.
You do have to plan out your software, I guess I kind of de ied that. I was wrong. You were right. Take your victory dance, then sit down, I'm not quite done yet.
>It's not "certainly less complex". The total complexity of the system is still the same.
The total complexity of the system is the same, yes, but the GLOBAL complexity of the system is significantly reduced: A lot of complexity is isolated, and if the components interact through well-defined interfaces, you can treat each as a black box (theoretically, once they work), and use them as building blocks to build your system. Every programming paradigm, language, and system in the last 60+ years is based around this idea, from structural, to OO, to Unix, to Lisp, to Microservices, and on to the next craze.
So, I assume that this something you agree with. In which case, congrats, you've convinced me.
The components aren't necessarily separate apps, but even if they are, that problem has been solved many times over. Take your pick: HTTP, raw sockets (TCP or unix domain), ZeroMQ, RabbitMQ for larger projects, Shared Memory, pipe(2) (and friends), hell, even message queues and semaphores, if you hate yourself...
I've yet to meet a requirements document that was good enough for both parties to agree that the contract had been fulfilled. It's almost always come down to browbeating or going unpaid.
What that requirements document is is a license to withhold payment until the contract obligations are met, no matter how ruinous those obligations are because of inattention to detail and the customer's complete lack of ability to state clearly what they want.
I think one of the biggest things us developers misunderstand about Agile is that it involves a contract that says you pay me every month for a month's worth of work. If 8 months into a 12 month project, the customer decides they don't like us, we've already cashed 8 checks and are free to pursue other projects. At worst I have 8 months of money and I have to scramble to find new projects for my team.
With the typical up front big design the customer just refuses to write a check until you've fulfilled their handwavy interpretation of the requirements, which mean whatever they want them to mean this week. We could easily be on month 20 still hoping to get our second check for 6 months' of pay. Essentially we're chewing people up and bankrupting the company in the process. It's a sucker's bet.
Lately I've gotten even more cynical. My new thesis is that companies that know how to ask for what they need and can break problems down into reasonable and measurable parts don't usually hire out work. They have all the necessary skills to just open job reqs and get their code written. The people who hire contractors seem to almost universally do it because they don't have the faintest clue how to spec and write a piece of software. Including doing the requirements. Especially the requirements. Be sure to quote them a rate that represents hazard pay, because there's gonna be drama.
I admittedly missed it up until "Never write technical requirements or functional ones." Then I started to re-read, and caught it throughout. Then again, I'm usually not even awake this early.
IMO, you're probably overthinking it. None of the other writings on the rest of the author's site suggests that any of the articles are meant to be satire or even that the author is capable of satire at this level.
> ... it's not about gobbling together the right tools and do some plumbing to make it work. No, it's using tools to craft a work of art. Anyone not recognizing this is an inferior software developer by definition ...
So — if you don't prioritize your ego and personal sense of artistry over accomplishing the task, you are an inferior developer? I would never want a person like this on my team.
I mean, I guess that's one way to interpret what he's saying... I interpret it as "have an eye for design and creativity to solve your problems, don't just be mindless and glue together frameworks and libraries". I personally think this is compatible with working on a team.
I've far too often seen code that does look like it's just a bunch of libraries glued together and if you really teased it apart you'd end up with something that's a lot less code and a lot fewer dependencies. And I definitely know people who wouldn't think twice about just adding another dependency to a codebase just so they could use one function. Sometimes that's justified, sometimes it's the result of lazy thinking.
While very idealistic and beautiful in a way as all manifests tend to be, we (along the author) tend to forget certain truths - the middle of the gaussian curve is fattest; all natural distributions follow that curve, and developers are no exception. Most of us, by definition, are mediocre. There's nothing that can be done about it. We should not shun, but rather embrace that. Not by deluding ourselves that if we follow some idealistic manifesto we somehow rise above our limited skills and minds. We will not. We will suck. Our tech will suck. Other peoples' tech will suck. There is no ideal that can be attained. This is not the profession of saints and Buddhas. But by knowing this, by accepting this, we can start working on raising the standard for mediocracy...
http://psychology.wikia.com/wiki/Bimodal_distribution lists other bimodal distributions: "the time between eruptions of certain geysers, the color of galaxies, the size of worker weaver ants, the age of incidence of Hodgkin's lymphoma, the speed of inactivation of the drug isoniazid in US adults, the absolute magnitude of novae, and the circadian activity patterns of those crepuscular animals that are active both in morning and evening twilight"
>A large number of natural distributions follow a power-law distribution.
This is surprisingly debatable. People like to find power-law/scale-free distributions because it implies a neat generative story, but a lot of the "evidence" for power-law distributions is pretty weak. For example, you cannot just show that a log-log plot is linear--lots of other distributions can produce similar plots.
Clauset, Shalizi, and Newman have a very readable paper where they describe 1) how to properly test for a power-law distribution, and 2) use those tests to assess the validity of some claims from the literature (spoiler: not many have "good" statistical support). Here is the paper: http://arxiv.org/abs/0706.1062 Shalizi has a short blog post describing the main results: http://bactra.org/weblog/491.html
Agreed. The old saying is "anything looks linear when plotted on a log-log graph."
However, the OP was giving a rough approximation in the first place, in saying that all natural distributions follow a Gaussian curve. But Gaussian curves go from -∞ to +∞. Many of the real-world distributions must only have positive values, like heights and weights. Although for real-world purposes, they can usually be approximated as Gaussian.
With that roughness in mind, I think it's okay to say that the Stefan–Boltzmann law, the inverse-square laws of Newtonian gravity and electrostatics, or Kleiber's law, which are all listed in the Wikipedia link are close to a power law to be acceptable counter-examples.
(Stefan–Boltzmann assumes a perfect black body, the inverse-square laws ignore relativity, and Kleiber's law is a rule-of-thumb in the first place.)
Oh sure. When there's a plausible reason for thinking something is scale-free, I'm all for it.
For a while though, it was en vogue to find power law distributions in all sorts of weird places (email response times, numbers of friends), and that's what I was attempting to object to!
Couldn't agree more with this. It's something I repeat at work almost once every week. Look I'm average, most of us at work will be average. The question is how to we design our processes to take that into account? instead of constantly pointing fingers for mistakes that happened.
Of course I can and I do but the wider group will still always have a Gaussian distribution of skills more or less always. (as pointed out by parent comment)
In my experience, this usually leads to having a team of "architects" whose job it is to sit in meetings with people actually building things and tell them how to do it. I've yet to meet anyone who can do that job well. No one is good enough to reliably prescribe solutions from afar without getting their hands dirty. There will be weirdness and corner cases and overlooked details that have to be accounted for. Going back to the architect who has been doing other things for the last six months isn't likely to yield much insight in what to do about that.
I think that in pretty much all cases, you'd be better off just taking that architect and telling him to write the code. If you don't think you have enough good people to do the amount of work you need to do with that approach, you're trying to do too much work.
Re-read the manifesto. You'll notice that its theme is not about a person's natural abilities or smarts, but self awareness. The manifesto can basically be boiled down to "show humility in your own code". Always assume that there is potential for improvement, and be ready for when that potential becomes a need.
It's about mindfulness towards our own product. "Mediocrity", in this case, is turning a blind eye towards our own limits. All people have the ability to overcome this form of mediocrity.
> This is not the profession of saints and Buddhas.
It's a choice, not a lifestyle.
Full enlightenment, or being a Buddha, is the realization all of this around you is Buddha Nature. Each individual is capable of attaining enlightenment in a single moment, given choice is made in very similar moments throughout the day. When you decide to believe it, you do so in a timeframe that is non-measurable. Like many people I know in SV, I believe we're running in a simulation. This belief could be viewed as equivalent to a type of enlightenment.
On the other hand, saints are beyond this reality and are "holy" in nature. Holiness means they have been re-integrated with the supreme wisdom, or all knowledge. Some call it the fucking oneness. Aldous Huxley called it the "burning brightness of unmitigated Reality". Technically, they are enlightened, but they are outside what we HERE can consider as Buddha Nature.
I liken these two concepts to security through obscurity. We don't know the proper protocols to realize that we are all the same thing and refuse to think about the fact we'll all be reintegrated into the brightness when it comes for us.
There lies a difference between Bodhisattva and Buddha.
What you described while explaining the difference between Buddhas and saints is essentially the difference between Bodhisattvas and Buddhas :)
And Bodhisattva is a lifestyle by choice.
But then again, what do i know. I barely follow the eightfold path.
Accepting being better than some people is accepting being worse than some other people. One thing is for certain; we all aren't just as good. Who is really ignoring reality? Is it the person who thinks he has room to improve or is it the person who thinks he can't improve and has no reason to improve?
"Therefore, our true purpose is to express the intentions of our clients using as little code as reasonably possible, accompanied with lots of documentation and lots of tests (testing code and unit tests don't count as LOC). We should distrust every line of code written by ourselves as well as those written by others. The best code has 0 lines. Because in zero lines of code, there is room for exactly zero bugs."
That depends on how you measure code. If you're talking lines or statements, sure, but if you're talking concepts then the code with fewer concepts expressed must necessarily have less opportunity for bugs, if the number of bugs per concept is held constant.
" The best code has 0 lines. Because in zero lines of code, there is room for exactly zero bugs."
I read it as lines... I agree with what you're getting at, sometimes the concepts are a lot simpler and less prone to bugs when implemented in more lines of code.
Less code does absolutely mean less bugs, in the majority of cases. Of course it is not an absolute rule and can be gamed, but simple logic dictates that since it is not possible to always write 100% bug free code, the more code one writes, the more chance there is to introduce bugs.
However I don't believe the statement was meant to be taken entirely literally.
Then why do I spend so much time fixing bugs in code where the concept was complicated to the nth degree so it could be written in five lines instead of ten?
I agree that fewer lines of code is better, unfortunately if you hold that concept in too high a regard it's easy to make a mess. Some programming challenges are complex and the complexity can't be avoided. Sometimes solving that problem in fewer lines of code makes the problem even more complex. Just because the complexity is moving from the code itself into the developers head doesn't NECESSARILY mean that it will be less prone to bugs.
Those 5 lines probably had 100s if not thousands of lines backing them. Maybe best to say 'fewer lines of code executed' as it doesn't really matter whether those lines are in a library or in your project, they still have a chance for bugs.
You're missing the point, it's not about executed code it's about concepts and simplicity.
Sometimes people work too hard to make two functions with slightly different objectives into a single complicated function. This can save lines of code since you aren't writing two similar functions. In general this is good practice but it's VERY common to take this too far, and it's very likely that the resulting complicated function will be MORE prone to bugs than the two simpler functions would have been.
The Unix command /bin/true (do nothing, exit with code zero) can be implemented as an empty file. When it's run, the kernel doesn't recognize it as binary code, so it gives it to /bin/sh to run.
There's at least two bugs in a zero-byte implementation of /bin/true: it's too slow and it uses too much memory.
php developer talking about
"It does not matter how many people use framework X."
and
"Never do requirement analysis. Never write technical requirements or functional ones. If you do, you have already failed."
This is fantastic; the perfect example of tilting at windmills. So, I'll take up the role of Sancho.
Using tools to craft a work of art? I'm sure some projects deserve our collective accolades, but no one should consider them art. The only projects that should end up in a museum are those that are no longer in use.
Risk of bugs increases with each piece of code? I'm sure this is impossible. The risk is already 100%: there will be bugs. They only increase in volume.
Always be wary of fancy websites? I'm sure the rant preceding this nugget has a point (e.g. maybe "never compromise on code quality), but let's be honest: a fancy website is a work of art, See #1.
Withstood the tooth of time? I'm sure these mixed metaphors are meant to be poetic, but when you lead with a statement followed by an exception, then your whiskey spigot can engender an acreage of Hidalgo.
This is either brilliant, or excellent satire. Which one it is depends on how you define the terms. There is good advice here, but if you take it literally, and don't pay attention to context, and use common sense, you'll end up with some really bad advice.
I'll never understand comparing code to art. Not the first time I'm seeing it but for me it couldn't be further apart.
There is no best way to make a drawing.
There is no best way to make a movie.
There is no best way to tell a story.
There is no best way to make a painting.
There is no best way to create a song.
...
There is (almost?) always a best way to do a piece of code. Code has nothing to do with emotions. I'm not trolling I truly don't get it, like at all.
This is a dubious assertion. Best is fundamentally a subjective metric. Code is only the best for a given set of criteria. What's best code for rapid development isn't best for maintainability. Sometimes you have to break maintainability for speed bottlenecks. Saying there's a best way to code something is a very contextual claim.
There is (almost?) always a best way to do a piece of code.
Nah....we can't even decide on a 'best' language to use. Or how to best indent, or where to put the braces, or what variable names to use. The code you write is a reflection of what's inside your mind, just like art.
I don't mean to be purely negative but this is so wrong as to be harmful. My one solace is that my marketplace competition may read this and thereby make themselves less effective pursuing some silly ideal of purity while I'm busy getting shit done.
This looks to me like a developer who is frustrated that nobody listens to him, who wrote a manifesto saying that everyone should do things in the way that HE thinks they should be done. Reading through the manifesto, it is obvious to me why nobody is listening to said developer.
109 comments
[ 3.3 ms ] story [ 178 ms ] threadUnfortunately, it does. It sort of makes sense Manifest Against Mediocracy includes such statement, since this is the large impediment in fight against mediocracy, but simply asserting it doesn't make it true.
We went from big frameworks to a bunch of libs.
Many people got into extreme and even used stuff like left-pad.
I try to only include third party software for stuff I don't have the time or skills to implement. This makes my utils directory a bit bigger, but that's it.
Did we forget a little detail here?
> Therefore, our true purpose is to express the intentions of our clients using as little code as reasonably possible, accompanied with lots of documentation and lots of tests (testing code and unit tests don't count as LOC).
I think it's fair to say that there is more code being written today, by a more diverse group of people, than ever before. It would be a real shame to tell them the amount of code they should be writing is 0 since that's the only way to prevent bugs.
>Never do requirement analysis. Never write technical requirements or functional ones. If you do, you have already failed.
In that case, how do you know when the software is finished and your contract has been fulfilled?
>Creative solutions are often holistic in nature, driven by first-hand experience, discussion, interaction and... thinking. If you want a developer to write a great piece of code, let him or her scratch the itch you're trying to scratch.
So, you do all your thinking, without capturing anything, and then the software is finished when the developer is bored?
I'm kind of sick of so many devs fighting to try and outsmart each other. I'm looking at legacy code basses where people wanted to have a go at a technology and it just became an unmanageable abortion because they move on, support picks up the gig and then rot. Now I'm learning obscure technologies not in use by the majority of the bell curve because someone had a thought bubble. -- end rant.
I'm all for the middle ground. Money flows to those who deliver.
The best software is built up over time as demand arises for those features. Create the feature requests as they are required and implement the requests.
I think one of the major causes of why this type of thinking ends up building bad software is that BAs include literally every corner case they can think of. Ends up being extremely complicated right from the start. Then they miss other requirements. If you build by evolving software from a simple beginning just to scratch an itch, you learn the true requirements from experience. Learning about the optimal architecture from experience as they go.
Hard to do when your working off a software dev contract. Fairly easy to do if your building a product.
It's cathedral vs bazaar.
Never mind that thoughtfulness of design is a requirement to understanding complex distributed systems. And before we go off saying that few developers need to know how to program distributed systems consider that even a modern processor is a tiny distributed system.
This idea that genius will spout forth from the hands of the programmer in the spur of the moment is hogwash. If you believe this then let's make a wager. We'll pick a simple, standard algorithm. I'll give you the requirements, you implement it. I'll model your solution and run it in a model checker. I bet you that the checker will find an error in your implementation. Simple, right?
A colleague of mine did this to his students. They had to implement binary search. The majority of their solutions had bugs. These weren't under-grads.
Programming is hard because thinking is hard and we deserve the best tools we can find to help us think clearly and precisely. In the real-world we can always just add a fudge-factor to make up for our uncertainty while computers are infuriatingly discrete systems.
This flow of "thinking in code," is simple-minded ignorance. Think in code all you want. You won't be able to solve the hard problems that way. You'll just write sloppy code.
... </rant>
Requirements analysis is also critical when the software is coupled to particular hardware or a particular process.
All you're doing is shifting complexity around. Don't want one big piece of complex software? Fine. Break it up - now you have a bunch of simple pieces of software that all need to work together in a complex manner. You still need to plan for how all that works, and that often requires complex requirements.
It's not "certainly less complex". The total complexity of the system is still the same.
You do have to plan out your software, I guess I kind of de ied that. I was wrong. You were right. Take your victory dance, then sit down, I'm not quite done yet.
>It's not "certainly less complex". The total complexity of the system is still the same.
The total complexity of the system is the same, yes, but the GLOBAL complexity of the system is significantly reduced: A lot of complexity is isolated, and if the components interact through well-defined interfaces, you can treat each as a black box (theoretically, once they work), and use them as building blocks to build your system. Every programming paradigm, language, and system in the last 60+ years is based around this idea, from structural, to OO, to Unix, to Lisp, to Microservices, and on to the next craze.
So, I assume that this something you agree with. In which case, congrats, you've convinced me.
http://www.smashcompany.com/business/the-agile-process-of-so...
What that requirements document is is a license to withhold payment until the contract obligations are met, no matter how ruinous those obligations are because of inattention to detail and the customer's complete lack of ability to state clearly what they want.
I think one of the biggest things us developers misunderstand about Agile is that it involves a contract that says you pay me every month for a month's worth of work. If 8 months into a 12 month project, the customer decides they don't like us, we've already cashed 8 checks and are free to pursue other projects. At worst I have 8 months of money and I have to scramble to find new projects for my team.
With the typical up front big design the customer just refuses to write a check until you've fulfilled their handwavy interpretation of the requirements, which mean whatever they want them to mean this week. We could easily be on month 20 still hoping to get our second check for 6 months' of pay. Essentially we're chewing people up and bankrupting the company in the process. It's a sucker's bet.
Lately I've gotten even more cynical. My new thesis is that companies that know how to ask for what they need and can break problems down into reasonable and measurable parts don't usually hire out work. They have all the necessary skills to just open job reqs and get their code written. The people who hire contractors seem to almost universally do it because they don't have the faintest clue how to spec and write a piece of software. Including doing the requirements. Especially the requirements. Be sure to quote them a rate that represents hazard pay, because there's gonna be drama.
It's certainly brightened up my Wednesday reading the comments on here.
IMO, you're probably overthinking it. None of the other writings on the rest of the author's site suggests that any of the articles are meant to be satire or even that the author is capable of satire at this level.
So — if you don't prioritize your ego and personal sense of artistry over accomplishing the task, you are an inferior developer? I would never want a person like this on my team.
I've far too often seen code that does look like it's just a bunch of libraries glued together and if you really teased it apart you'd end up with something that's a lot less code and a lot fewer dependencies. And I definitely know people who wouldn't think twice about just adding another dependency to a codebase just so they could use one function. Sometimes that's justified, sometimes it's the result of lazy thinking.
No True Scotsman at its finest.
No, they don't. Many approximate that curve. Others do not. For examples:
"Bimodal distribution of flowering time in a natural hybrid population of daylily (Hemerocallis fulva) and nightlily (Hemerocallis citrina)" - http://link.springer.com/article/10.1007%2Fs10265-005-0241-3 .
http://psychology.wikia.com/wiki/Bimodal_distribution lists other bimodal distributions: "the time between eruptions of certain geysers, the color of galaxies, the size of worker weaver ants, the age of incidence of Hodgkin's lymphoma, the speed of inactivation of the drug isoniazid in US adults, the absolute magnitude of novae, and the circadian activity patterns of those crepuscular animals that are active both in morning and evening twilight"
A large number of natural distributions follow a power-law distribution. https://en.wikipedia.org/wiki/Power_law#Examples gives many examples.
That said, you do not need that broad claim to make your argument.
This is surprisingly debatable. People like to find power-law/scale-free distributions because it implies a neat generative story, but a lot of the "evidence" for power-law distributions is pretty weak. For example, you cannot just show that a log-log plot is linear--lots of other distributions can produce similar plots.
Clauset, Shalizi, and Newman have a very readable paper where they describe 1) how to properly test for a power-law distribution, and 2) use those tests to assess the validity of some claims from the literature (spoiler: not many have "good" statistical support). Here is the paper: http://arxiv.org/abs/0706.1062 Shalizi has a short blog post describing the main results: http://bactra.org/weblog/491.html
However, the OP was giving a rough approximation in the first place, in saying that all natural distributions follow a Gaussian curve. But Gaussian curves go from -∞ to +∞. Many of the real-world distributions must only have positive values, like heights and weights. Although for real-world purposes, they can usually be approximated as Gaussian.
With that roughness in mind, I think it's okay to say that the Stefan–Boltzmann law, the inverse-square laws of Newtonian gravity and electrostatics, or Kleiber's law, which are all listed in the Wikipedia link are close to a power law to be acceptable counter-examples.
(Stefan–Boltzmann assumes a perfect black body, the inverse-square laws ignore relativity, and Kleiber's law is a rule-of-thumb in the first place.)
For a while though, it was en vogue to find power law distributions in all sorts of weird places (email response times, numbers of friends), and that's what I was attempting to object to!
I think that in pretty much all cases, you'd be better off just taking that architect and telling him to write the code. If you don't think you have enough good people to do the amount of work you need to do with that approach, you're trying to do too much work.
It's about mindfulness towards our own product. "Mediocrity", in this case, is turning a blind eye towards our own limits. All people have the ability to overcome this form of mediocrity.
It's a choice, not a lifestyle.
Full enlightenment, or being a Buddha, is the realization all of this around you is Buddha Nature. Each individual is capable of attaining enlightenment in a single moment, given choice is made in very similar moments throughout the day. When you decide to believe it, you do so in a timeframe that is non-measurable. Like many people I know in SV, I believe we're running in a simulation. This belief could be viewed as equivalent to a type of enlightenment.
On the other hand, saints are beyond this reality and are "holy" in nature. Holiness means they have been re-integrated with the supreme wisdom, or all knowledge. Some call it the fucking oneness. Aldous Huxley called it the "burning brightness of unmitigated Reality". Technically, they are enlightened, but they are outside what we HERE can consider as Buddha Nature.
I liken these two concepts to security through obscurity. We don't know the proper protocols to realize that we are all the same thing and refuse to think about the fact we'll all be reintegrated into the brightness when it comes for us.
And Bodhisattva is a lifestyle by choice.
But then again, what do i know. I barely follow the eightfold path.
"Therefore, our true purpose is to express the intentions of our clients using as little code as reasonably possible, accompanied with lots of documentation and lots of tests (testing code and unit tests don't count as LOC). We should distrust every line of code written by ourselves as well as those written by others. The best code has 0 lines. Because in zero lines of code, there is room for exactly zero bugs."
Less code does not necessarily mean less bugs.
I read it as lines... I agree with what you're getting at, sometimes the concepts are a lot simpler and less prone to bugs when implemented in more lines of code.
However I don't believe the statement was meant to be taken entirely literally.
I agree that fewer lines of code is better, unfortunately if you hold that concept in too high a regard it's easy to make a mess. Some programming challenges are complex and the complexity can't be avoided. Sometimes solving that problem in fewer lines of code makes the problem even more complex. Just because the complexity is moving from the code itself into the developers head doesn't NECESSARILY mean that it will be less prone to bugs.
Sometimes people work too hard to make two functions with slightly different objectives into a single complicated function. This can save lines of code since you aren't writing two similar functions. In general this is good practice but it's VERY common to take this too far, and it's very likely that the resulting complicated function will be MORE prone to bugs than the two simpler functions would have been.
There's at least two bugs in a zero-byte implementation of /bin/true: it's too slow and it uses too much memory.
Trolling at its finest.
Using tools to craft a work of art? I'm sure some projects deserve our collective accolades, but no one should consider them art. The only projects that should end up in a museum are those that are no longer in use.
Risk of bugs increases with each piece of code? I'm sure this is impossible. The risk is already 100%: there will be bugs. They only increase in volume.
Always be wary of fancy websites? I'm sure the rant preceding this nugget has a point (e.g. maybe "never compromise on code quality), but let's be honest: a fancy website is a work of art, See #1.
Withstood the tooth of time? I'm sure these mixed metaphors are meant to be poetic, but when you lead with a statement followed by an exception, then your whiskey spigot can engender an acreage of Hidalgo.
There is no best way to make a drawing. There is no best way to make a movie. There is no best way to tell a story. There is no best way to make a painting. There is no best way to create a song. ... There is (almost?) always a best way to do a piece of code. Code has nothing to do with emotions. I'm not trolling I truly don't get it, like at all.
Nah....we can't even decide on a 'best' language to use. Or how to best indent, or where to put the braces, or what variable names to use. The code you write is a reflection of what's inside your mind, just like art.
This looks to me like a developer who is frustrated that nobody listens to him, who wrote a manifesto saying that everyone should do things in the way that HE thinks they should be done. Reading through the manifesto, it is obvious to me why nobody is listening to said developer.
For that matter, manifest != manifesto.
Probably English isn't the author's first language. I should forgive him and carry on, but a quick scroll reveals the words idiot and whiskey. TL;DR
The power of peer review!
Uh, I kinda like the tone, but this guy might not be familiar with the decades of math and engineering that back something like Haskell.
It's true, there's an art to writing software, but...
Tools (practices, ideas) that have been honed and refined to the point that they are reflections of physics and logic aren't to be dismissed.
Those tools are to be wielded by artists!