525 karma · joined September 6, 2018
I liked the advice because it actually applies to good processes that become embedded in the everyday work.
The point of the article being in how to prepare for the cases when a good policy becomes broken or is abused over time.
Wow, what a great piece of advice. It seems so obvious and simple in retrospect and yet I never thought about something like this.
I exaggerated that one, it has value, but to a lesser degree, imo. The value of the painting is in the skill of producing the copy, not really in having the creativity or insight that the original photographer had when taking the photo. The subject is already in 2d, perspective already frozen, and if you're replicating it perfectly you're not adding anything substantial, you're just changing the medium.
Can a copy be considered art? Sure it can, like I said previously anything can be art if framed in an artistic context. I wasn't trying to be sarcastic.
> You seems to insist on one definition of art, which is super strict and exclusive.
I don't think I've tried to define or limit what can/cannot be art in any of my comments. I'm just talking about my personal criteria for differentiating between different levels of artistic quality.
My top comment in this thread merely stated that using someone else's photographs to photocopy into a painting without applying your own insight is a less-creative form of art than if you are framing and taking a picture yourself and you use that as an intermediary medium before copying it to the canvas.
Me building a wooden chair by looking at a picture on ikea's site is a form of craftsmanship. Can it be called art? Sure it can, I might even take a picture and post it on reddit. Is it great art? By my criteria, no. I would say that a chair built by Gaudi has more artistic value than my chair, and please note I'm not saying that my chair isn't a piece of art, just a lesser one.
If someone finds my preserved wooden chair in 1000 years it's historical value would be great but I wouldn't be so sure about it's artistic value, unless it's the only remaining representation of a chair left from the 21st century in any kind of medium.
my point was that it feels weird for me to call it art if you didn't take the photo and your just doing the last, arguably less creative, step.
Not that it doesn't take a great deal of effort and skill to achieve it, it just feels somehow "lesser".
One can argue that doing an exact copy of a photograph with the end result being indistinguishable from the original photo is some kind of "meta" art and the lack of creativity actually puts focus on the technical skill and the effort of the artist, as a kind of "anti-creativity statement" type of art, "there is no artist just paint and effort".
But my non-artistic brain would still rate this lower compared to the original in terms of creativity, insight, originality.
Yes you can raise a skill to the level of an art, but then wouldn't the actual performance of the skill be the artwork? And the resulting picture just an artifact that has no artistic value without the original side by side + a description/video describing/showing the actual effort?
On that note, I think I'll stop. I feel I'm getting high just from all the meta-ideas I'm writing, lol.
I feel like I'm going to deep into this "art" thing so time to get back to a domain where I have more experience, software development.
Being great at touch typing is an awesome skill that many people train but typing fast doesn't make you automatically a great developer/architect/manager.
I see the effort of exactly copying someone else's photo similar to how developers do "coding katas" to hone their fundamentals. It's basically practice, not really creative problem solving.
Nothing wrong with honing one skills, but in my book skills are tools to be used as part of a creative process. They don't replace the creative process, but they can elevate the end result.
I guess my scenario was much more narrow, as I was thinking about doing an exact copy of a photo that you didn't take yourself. Doing an exact copy limits greatly the number of artistic choices you could make as most of the choices were made by the photographer.
Just found out this is actually a thing called photorealism where the artist is expected to also take the original photo. Feels good to read about something else than software and politics for a change :).
Yes there are many photos that you can call art, but if you're not the one that took the original photo it feels like most of the creative effort was not yours and you're just showing off your brush/pen technique.
As a disclaimer, I have 0 talent when it comes to drawing/painting so I'm pretty much clueless about the creative process of modern painting.
Is Einstein a greater scientist than Newton? Are both of them better than Galileo? Now that would be a fun discussion at the pub, but with no real value. All of these guys benefited from previous work done by other "masters" and this helped them reach even greater heights.
Even in sports like chess, where it's a lot easier to compare matches and ratings across decades and even centuries you could debate that the old masters had a fraction of the resources available to current masters so the comparison doesn't really hold.
I think the main cause is the low barrier for entry. It's great that anyone can get started quickly and be successful but it also means that the resulting mess can be at a level that you rarely see in other stacks where the barrier for entry is a bit higher.
I can clearly see that the PHP ecosystem is there (mature libraries for mocks, tests, etc) but like you said, there are people that just don't care. The language and ecosystem evolved faster than a big chunk of the developer community and I don't think everybody will catch-up anytime soon, as old PHP code bases can still generate a nice revenue doing maintenance.
Parts of the community seem to want to go over that limitation so things like Swoole and Roadrunner were developed. I guess it's interesting to have both options available even though much of the ecosystem won't readily function in both contexts.
While the ecosystem seems a bit weaker that what I would expect considering the number of developers (comparing to Java, Ruby, Python) I don't have a strong opinion on package management. I feel like all major platforms have gotten into pretty good shape on this front. Like you mentioned, if I start a new Python project I can just choose Poetry and avoid most of the drama.
In my case if the hosting provider doesn't have something like DigitalOcean's droplets I'll still rely on docker compose instead of the default stack deployed on the system whatever stack I'm choosing. But yeah that's raising the bar too much for most people especially for a couple of scripts or pages.
In the meantime I switched to other stacks but I've been keeping a distant eye on how PHP was evolving and I still am involved with PHP projects to a certain degree, though rarely at code level.
I really appreciate the effort put into fixing most of the things I hated about the language, though at times it felt like the language and some of the frameworks were trying too hard to copy the Java ecosystem, all while Java itself was starting to modernize.
I'm curious what is the value proposition of the latest PHP version(s). Why would I choose PHP when starting a greenfield project? I know one of the easiest answers is that there's a huge amount of developers worldwide that know PHP, but apart from this obvious reason is there anything else that would make someone choose PHP ahead of other stacks?
But I think this point also opens another subject, preventive healthcare. Many modern healthcare systems are starting to focus on prevention for 2 main reasons: increase quality of life and reduce long-term healthcare costs.
For example, in Finland public tobacco smoking is(was?) considered a public health issue. The government got actively involved to reduce consumption and this resulted in better overall outcomes in their healthcare systems for diseases caused or exacerbated by smoking.
IMO, obesity is a problem affecting the healthcare systems of many developed countries (Vietnam is not yet considered a developed country) arguably not at the same levels as in the US. But this again is part of how government chooses to get involved in fixing the healthcare system by enforcing policies or passing laws that help with prevention.
Please note that the wording implies that 18% of GDP is spent on health care overall not that the US Government is spending all that money out of its pocket directly on yearly budgets. The way I understand it is that it includes both money spent by public and private actors for all health related service.
I see this type of stat a warning that something might be dysfunctional within the system, and it's the government's job to get to the bottom of it.
The point I was trying to make is that government involvement is needed to make sure that the right incentives are in place at all times for all involved actors (public or private). And if the system becomes dysfunctional or is abused it's the government's job to fix it.
Most of the countries that have universal healthcare in Europe have their own take on how it should be done: - France has state funded insurance and (mostly) state funded services - Switzerland private insurance and private/public services
Two totally different takes with arguably very similar (good) results.
The goal of government involvement should be to make sure everyone has access to basic healthcare and avoid double standards and abuse.
Well that's the point, I think everybody should be taken into account in order to paint a comprehensive picture of the quality of the system at country level. The resulting stats reflect the health of a society as a whole not just of the part that can afford it. Not having universal healthcare is still part of the system, even if we don't like it.
I get it that health outcomes of those left out are probably very different. But leaving those numbers out of the comparison doesn't really work with these type of statistics.
At that point how could you compare it to the other countries that take everyone into consideration? The stats are GDP/capita percentages, should I remove the ones who can't afford healthcare from the GDP stats as well to not skew the ratio? I don't really like where I might end up taking this route.
I don't have any experience with US healthcare and I'm sure the quality of the services is really high, but the fact that you need to afford basic healthcare and it's not guaranteed by the government for everyone makes me see it as closer to just another "consumer product" compared to other systems.
Another point is that US healthcare is considered the most expensive and worst-performing in terms of outcomes compared to the other developed countries.
So you basically get the worst performing being also the most expensive. Which doesn't really fit the view that less government involvement results in a more efficient system. Well, I guess it is more efficient if the expected outcome is a larger profit for different private companies and middlemen and not the well-being of the rest of the population.
My hope is that this new-found energy in healthcare products doesn't follow the traditional VC-backed approach of building a product, taking over markets through aggressive marketing and shady closed-door dealings and operating at a loss only to then monetize the shit out of everything.
Theranos really embodied some of these fears, and I'm not sure we'll live in a better world if our health will be in the hands of people that have a financial incentive to tell us we're more sick/healthy than we really are.
That seems like a very short amount of time to expect complete trust.
It's pretty normal that the old team has more trust. They put in the effort to get the product where it is today.
If you plan to stick around you should put in the effort, prove your worth and gain the trust of the CTO, before challenging the status quo.
I think many software developers who love what they do go through that kind of phase in their careers. I got over it after realizing that results come first and written code is not a weightless piece of art. All code is tied directly to the value it provides. The best codebases I worked on were far from perfect but they were owned by teams who had a clear understanding of the tradeoffs needed to be made at different places in the code. Business critical code, subject to continuous new additions/changes, was refactored multiple times per year and kept in a state close to what the poet in me craved in the past. But the value proposition for this was clear for everybody. On the the other hand many places in the code were far from that level because it didn't make any sense to invest that kind of effort everywhere.
> My hunch is this: folks can’t talk about real design systems problems because it will show their company as being dysfunctional and broken in some way. This looks bad for their company and hence looks bad for them.
I guess it's natural that people prefer to present and discuss their successes more than their failures. After so many years reading this types of blog posts my understanding is closer to 'Oh look at a big problem that we had and how we managed to solve it in an elegant way' instead of 'We have no problems whatsoever, we do everything perfect and this is one of those examples'.
> The ugly truth is that design systems work is not easy.
Design systems are basically UI frameworks. Building a framework, keeping it up to date and continuously evolving it is far from a simple task that can be done while also delivering new features on time using said framework. And as the system grows the complexity keeps on rising.
At many companies it's hard to justify the needed level of effort especially if they are not in the business of building frameworks or don't sit on a mountain of cash. A handful of talented people will dream of building something cool and will invest their time (and sanity) into this type of effort but they often bite off more than they can chew.
While oversimplified, it can serve as a good example on how an initially rational practice could easily became dogma even when the initial stimulus is no longer present.
Part of my day job in the past 2 years has been to consult a client in refactoring/rewriting an old platform. The client's old team is still in place and even if we've added some new people just to try and change the mindset, the inertia of the spaghetti codebase coupled with the client's short and mid term financial goals as well as the "traditions" of the old team has stopped us from enacting any groundbreaking changes.
I guess the moral is that there are many forces at play in this kind of setup and stories like these can help in framing some of them in a fun way.
A group of monkeys in a room. In the center of the room is a tall pole with a bunch of bananas suspended from the top.
Every time a monkey tries to reach the bananas it is hit with a torrent of cold water from an overhead shower. Eventually, the monkeys learn that something bad will happen if they climb up the pole so they just sit and don’t even try again.
If a new monkey is added to replace an old monkey, it will of course try to go for the bananas. But the original monkeys will grab and drag it down before the punishment is even triggered. After a while, the monkey gets the message and it stops trying.
Repeat the action of adding a new monkey in place of an old one enough times and you will reach a point where none of the monkeys know why they shouldn't get the bananas but they still won't try.
The story concludes by stating that even if we remove the shower at this point it won't really make a difference. The learned behavior is already deeply ingrained in the culture of the group.
Funny enough, I've seen this type of issue in many human teams/projects. And usually the inertia is far too strong for just a couple of engineering "monkeys" to radically change things if they don't get support from a few management "monkeys".
How do they reach consensus when there are conflicting opinions? Popular vote? How is majority established? Half+1? How do they keep in check the formation of factions or short term alliances that are so typical in any human group larger than 2?
While not stated in the article I'm guessing that the "masters" act as an informal leadership team tasked with overseeing the whole process. Also they hint to having a hiring process that clearly filters for culture fit, I'm sure that helps.
But the thing that probably helps the most with keeping egos and abuses in check is the fact that 50% of profits is shared with staff. It's likely that the salary differences are not that relevant if your yearly revenue tops what the market is paying for your level of experience
But I'm trying to have a more nuanced perspective. My goal is to be a specialist in a couple of practices less likely to change not in the tools that are more likely to change.
For example, as a developer I would want to become a specialist in Object Oriented Design, not in Java/PHP/etc. I might not understand all the nooks and crannies of Java and the JVM but I understand enough to get the work done in 90-95% of cases and I'm comfortable enough to get my hands dirty with the official documentation in order to deliver good work in the rest 10% of cases. Yes it's quite probable that a Java specialist will be more effective than me in those 10%, but having a wider breadth of knowledge makes up for it in other areas of the project.
In my experience I can cover most of my lack of knowledge in a certain tool much quicker if I already have previous experience in switching tools. I'm becoming better in understanding what I can take and apply from my less-specialized expertise and what I need to learn quickly in order to minimize the impact of my "generalism".
Another interesting thing I noticed is a cross-pollination effect, I can bring experience from other tools and provide a completely fresh perspective in solving problems compared to specialists that otherwise wouldn't have even considered some of the new possibilities.
My point was more focused on your example about footwear and on the fact that just using deduction or other reasoning techniques without starting from real archeological proof can easily lead one astray.
So I'm not trying to compete on which hypothesis about footwear is better I just gave that example in support of the point I just mentioned above.
For example, I could formulate a completely different hypothesis about how footwear appeared:
- doing any kind of activity on rough terrain while barefoot increases the risk of injury, like cuts or punctures
- any kind of wound could easily infect and lead to death
- the easiest would be to try and protect my feet wrapping something like leaves, animal skins, etc around my feet
- this is a good solution but this footwear isn't very resilient, hmm, maybe tree bark would work better, it's still flexible but should be more resilient.
- hmm, what else could I do that is better than tree bark, maybe some dried animal skin would be even better
- and so on...
So yeah deduction and induction can get you very far but when we're missing so many facts on which to base our hypothesis you can easily get very far in a very wrong direction. This is why I think archeology is fun.
EDIT: The wikipedia page on footwear also contains a few lines that add another interesting dimension:
> Some ancient civilizations, such as Egypt and Greece however saw no practical need for footwear due to convenient climatic and landscape situations and used shoes primarily as ornaments and insignia of power.
But I think a lot of developers actually build software that is used by the same people mentioned in the book/article to be more productive at doing their bullshit jobs. And they're happy about it because it feels like they're providing real value to real people.
Also, most of the "enterprise" code I've seen written in the past couple of years was written to justify some big budgets and salaries, while the actual value provided by the related projects was questionable at best.
It's just that when you're a developer focusing on solving a problem you've been assigned, you're just to happy playing with your new toy to even ask yourself if you're actually solving a real problem or that shiny new feature is just something added by someone in a backlog to justify his salary.