> not sure why Japan is being singled out here. Nearly every culture has celebrations that are then commercialized.
Japan takes it to another level though. In Europe I had never seen so much products customization happening across multiple categories at the same time.
Do they? In the USA there's Christmas merchandise in every store for 2 months. People buy trees, cars, tree decorations, candles, wreaths, house lights, cakes, egg nog, etc. etc. For Halloween custom stores open all over the place for 1-2 months, candy companies come out with all kinds of special candies, pumpkin patches show up all over town, and on and on.
Agreed. All of this is, I think, in some form, celebrating agricultural cycles, yes? Those are celebrated and turned in to holidays for good reason. I don't see why it's more interesting that it happens in country A vs. country B. But, that's just the world we live in.
What I've noticed is rather it's culture. Cherry trees blossom all over the world as do other trees. Almonds, Plums, Jacarandas, lots of others. Nothing special about cherry trees except they got lucky that one culture decided to celebrate them and others didn't
Yes, part of my point was it's just culture. I grew up in Los Angeles. I lived in Japan for many years and got used to the various celebrations. I then came back to Los Angeles and noticed all the trees blossoming that I and pretty much everyone else had ignored in the past.
So re post above, it's not the cherry trees are especially pretty. It's only that some people in Japan started appreciating them and promoting that appreciation until it spread throughout the country. It could just as easily have been any other blossoming tree or any other country. The only difference is culture not trees.
make it more like Japan means privatizing the public transportation and giving the companies running the lines the ability to buy and own real estate in and around the stations as well as not giving all lines to one company
IANAL but I'm pretty sure Getty is guaranteeing you won't get sued
From their license
> Warranty of Non-Infringement. For all licensed content (excluding content marked “access only”), Getty Images warrants that your use of such content in accordance with this agreement and in the form delivered by Getty Images (that is, excluding any modifications, overlays or re-focusing done by you) will not infringe on any copyrights or moral rights of the content owner/creator.
Note, I have many photos CC-BY on Flickr. One company wanted to use an image I took in the Louvre and wanted me to sign a different license. I refused as their license required I indemnify them and I had no idea what the legality of that image is given it was taken inside the Louvre
I wrote some basic for the first time in like 25 years. Forgot how there were no local variables nor parameters to functions. Everything is a global variable and GOSUB is just GOTO with a return stack (no parameters). Also forgot depending on the BASIC that some BASICs only allowed 2 letter variables.
Those were my biggest issues trying to get back into it.
Also forgot depending on the BASIC that some BASICs only allowed 2 letter variables.
For those not familiar with these systems, the way you coped was usually by keeping a "data dictionary" on a sheet of paper.
On a sheet of paper you'd have...
$AA = Name of foo
$AB = Selected color of baz
$AC = Blah blah
$AD = Length of qux
etc.
It wasn't TOO bad. Until you lost the damn thing, or had to work on somebody else's code and you didn't have the data dictionary. You could keep the data dictionary in the code's comments, but on systems with just a few kilobytes of RAM (ie, the systems that restricted you to 2-char identifiers) this was not always a feasible luxury.
Luckily, I managed not to have to deal with this personally. All the BASIC environments I used as a kid in the 80s did not have this limitation. But I heard horror stories.
Yes, but the systems with two-char identifiers were also the ones with the most extreme RAM restrictions.
Some commercial Apple II software was actually written in BASIC, and you could read the code. It was usually fairly liberally commented. Example code in magazines was liberally commented as well. Folks didn't seem to comment individual lines of code, but tended to "name" and sometimes describe their GOSUB (subroutine) blocks.
But, Applesoft basic didn't force you to use two character variable names. Because most Apple II's on the market had a luxurious 64KB or 128KB of RAM, and none had less than 48KB.
I think it was a different story on systems with 4KB or perhaps 16KB of RAM. On those systems I bet you were often squeezing out every byte.
I also think some older languages (COBOL?) often had restrictions like this.
Yeah there are a lot of limitations, and to make it more fun the limitations were different across computers at the time.
I wrote a simple BASIC interpreter recently in golang, and I'm amazed I had the patience to write "large" programs in BASIC in my youth with the limitations that were present.
> I'm amazed I had the patience to write "large" programs in BASIC in my youth with the limitations that were present.
what else did you have to do with your time? :)
i've had similar thoughts, but looking back, outside of gaming, the entire use of the computer, for me, was keying in programs. some were from others (in magazines/books), and some were learning to write my own. for the first few years of having one, i had no bbs connections, so... there was really nothing else to do except read books/magazines and type in programs.
I guess that's true! I switched from writing in BASIC to writing in Z80 assembly after a year or two - though it has to be said that I "compiled" my program by hand, referring to the opcode table(s) at the back of the manual.
My resulting programs tended to look like this:
10 FOR N=60000 TO 60000 + 20
20 READ A
30 POKE N,A
40 NEXT N
50 RANDOMIZE USR 60000
100 DATA 1,2,3,4,5,....
As you can imagine it was a tedious process. Most of my time was really spent trying to hack games for extra-lives, which I guess wasn't so unusual back in the day. Later I used the same skills to patch binaries to accept serial numbers - before I started writing real code in C, Java, Perl, etc, etc.
I had an opposite experience. OKRs were a complete waste of time. I was required to waste hours trying to come up with OKRs, none if which had anything to do with what my actual day to day work entailed. The OKRs were then promptly ignored so I could got back to getting shit done. At the end of the ORK term of course they'd been ignored. This had the effect of being demotivating because I was being asked to make up these OKRs "because at this company we have OKRs" but then having zero time and zero motivation to pursue them since there were people waiting for my real work to be finished.
I think discussing this requires getting clear on what OKRs are. At the company I was at they were broad personal goals set every 3, 6 or 12 months related generally to your career at the company. They were not related to any specific project or deadline.
An example might be "Do more public speaking". Where as generally I'd speak if the opportunity came up but I wouldn't seek out opportunities and AFAIK the OKR didn't make me seek more out. It was just something I wrote to get management to sign off that I had written some OKRs.
Sounds like the process was not done well at your company. I have my OKRs set up so that I spend almost all my time working on them. I do usually have one or two "personal OKRs" like the one you described, but most of them represent the team's core work: "put major feature X into production", "address P1 customer issues with 3 days", whatever.
It gives you a nice defense when some seemingly urgent but less important work comes along. "We could do that, but it would cost us this OKR which we agreed at all levels was one of the most important things for our team to do."
You could have said: these OKRs have to describe my actual work... here are my attempts to document what that means, and what to look for if I do a good job at that.
If they had pushed back on that, I think you would have a leg to stand on, but as described it sounds like you were just unwilling to engage.
Deadlines are effectively reality for many projects because tons of people and scares resources need to planned around them. Rallying against them is unrealistic
Let me give some examples:
You're making a product for retail. The stores that will carry your product need to plan to have their shelves full of product. That means they need to know when your product will be available. What promotions will appear on posters, flags, etc in the store. They need the plan this 6 months in advance so you have to commit to a deadline well beyond your finish date.
You plan to run commercials. The TV companies need to know sell their commercials months in advance. So you commit $$$$$$$ to pay for those commercials 6 months in advance. Miss your deadlines and there will be no product when your commercials run.
You're adding features to a mobile OS. Your partners (Samsung, or Sony, or LG or Motorola) are planning all of the stuff above (PR, Commercials, retail placement). They are going to be touting your new feature. Because they have to commit to ads and shelf space months in advance you also had to promise your feature will be ready months in advance.
I'm sure there are better examples. Here in Tokyo they getting ready for the Olympics. The venues, transportation changes, etc have a hard deadline.
Video games used to (still?) have all the same issues. 6 - 9 months before Christmas you have to promise the stores your game will be ready and on their shelves. That may change in the future but even in 2019 retails sales of bluray PS4/Xbox and Switch SD games are greater than online for the majority of games.
If you happen to be on a project that can run without deadlines and things get done and shipped whenever then lucky you.
If a project must have a deadline then I think there needs to be flexibility on what features are included.
For some features you can only know how long they will take once you get started on them. The overall business requirement has a deadline, but individual features may not.
The worst kind of deadlines I've experienced are we must have X by Y date, where the Y date is imposed by someone outside of the team without really thinking it through, and the only way to achieve it is via overtime and cutting corners.
This can also happen when you the dev says "10 days" then they get haggled down to "2 days" by their boss. Having split the thing up into 100 pieces and have those pieces individually negotiated, you end up with a hack solution. That kind of project, one way or another is going to go to shit. It may be delivered on time but it'll be a turd. Or it will just be late.
Absolutely. I’m in the midst of a project like this right now. PMs and Devs suggested a launch date of August/September but the Execs arbitrarily mandated mid-April. So, design gets rushed, Devs have to work overtime and half bake everything, and what should have been a great new venture for the company is probably going to be dead on arrival.
> where the Y date is imposed by someone outside of the team without really thinking it through
From my experience this is arguably the biggest factor I have seen for a project to fail. Not all realistically planned projects are successful but unrealistically planned projects become woolly very quickly.
> when you the dev says "10 days" then they get haggled down to "2 days" by their boss.
Devs are typically optimistic in their estimates. Having someone who won't do the work put any kind of downward pressure on an estimate is a great way of getting uninformative estimates.
In my experience this is largely a function of environment.
If you give a realistic estimate and constantly get "stop padding your estimates" or "this needs to be done quicker" in response, after a while you start giving hopelessly optimistic estimates.
You might be right, however what I've often observed is that people will estimate a task based on how long it would take them to do it if that were their only responsibility. They often ignore the fact that they don't get a full days worth of solid, productive coding due to meetings, build problems, releasing, code review, recruitment, fire alarms, sickness, status reporting...
As I recall, at IBM they used to give 3 estimates, best / expected / worst case, and then weight them something like 1/3/5 to get the planning estimate.
One person I worked with recorded estimate vs actual for multiple years. They were frequently an order of magnitude out.
Artistic things can have deadlines more easily because you can simply decide what constitutes good enough.
Functional things have to work...or they aren’t shipping. They can decide good enough on refinements and UX...as long as it works.
It that sense, there are very few real deadlines around functional things. If it doesn’t work, it’s not shipping yet...meaning it’s not really a deadline.
I'm used to seeing (and feeling) the inverse: people are far too likely to sum everything up into a simple, but too often wrong, explanation (he says with irony) Care to explain your reasoning for why it is overused?
I agree that too often sweeping statements are made and there are cases where finer details matter, and...
I see it as a form of one upsmanship, like wine tasting when the term is used. Other times, it's used to suggest that there's some detective work going on when the case is not so subtle or sometimes even incorrect. Or maybe I just have a narrower definition of subtle. I also prefer to use the term for analogue things rather than discrete ones. No matter how small a discrete case is clear cut.
I agree with you. Nuance is something you don't see acknowledged and used sufficiently. Everything is made to be black or white when it's mostly grey all of the time. At the same time, constantly staying in nuances prevents you from moving forward, so there's that.
Deadlines are also a way to manage resources and priorities. If something doesn't work, knowing when that thing needs to work by helps you determine if it's worth it to add more people or pay extra overtime, etc.
Well i don't think it is easier with the Artistic things. For exactly those reasons you mentioned never know when the work is done. It's also hard to estimate how long stuff will take and people fall asleep meaning you might be less intensive in your work than you should be because you have no idea you are behind schedule.
That’s not really true. Define “works” if I’m adding the ability to export a document. Is .txt enough or would my users actually want an image? Or a pdf? Or at least .csv? Maybe .txt would satisfy the power users but just upset the less computer savvy ones? Is it better than nothing?
If you have a release deadline for a quarter and PDF export is supposed to be part of the release, if the export does not work will you ship the feature?
You're either going to "hold the release" or you're going to release without the feature...because shipping with the broken feature will only create a huge support burden and a negative perception of your product.
I don't have any first hand experience but I have several Japanese friends that got diagnosed with mental illness or depression and given paid months off work by doctor's recommendation, something I'm not aware of in the USA
Christmas, Halloween, Valentine's Day, July 4th (USA), Spring Day, Flower Day, Day of the Dead, St Patrick's Day, etc etc etc.