Original Post — Direct link

TL;DR: Tyler1 ends over 2/3rds of his streams with a win.

I’ve been watching Tyler1’s jungle stream every night, and I check his op.gg every morning to check his early morning 3:00AM progress that I was unable to watch. I noticed that more often than not, his most recent game was a win. So I decided to conduct some research.

Hypothesis:

Tyler is less likely to quit on a loss. T1 alpha as f*ck.

Method:

I used the Riot API to pull data on his op.gg. First, I identified sessions that correspond to streams. I defined a session to be 5+ consecutive games, with over a 6-hour break (sleep) between the last game of the current session and the first game of the next session. I gathered the game IDs of the last game of each session.

Then, I simply checked whether Tyler won each game by comparing the winning team with the team of his IGN. I omitted sessions that ended with a non-ranked game, mainly to filter out the leveling process of his jungle account.

Results:

IGN “BUZZLIGHTYEAR99”: 12/15=80% of sessions end with a win. This isn’t the most conclusive, as it’s a small sample size, and his winrate is above 50% due to smurfing anyway. Impressively, his last 9 sessions have ended with a win.

IGN “S8 IS SO FUN”: 58/86=67% of sessions end with a win. I would have fetched more games but I reached the API limit.

Conclusion:

Tyler1 ends over 2/3rds of his streams with a win. T1 alpha as f*ck.

tyler.py

External link →
about 4 years ago - /u/riotaredherring - Direct link

Originally posted by reddit0r5

yeah, if you got into programming via an unusual way, it can happen that you do not have a github account, stackoverflow etc

Many programmers and software developers etc do not even know how wrong and how far away from their meant use some programming languages are being utilized.

while i was studying for my scientific degree I first got in contact with c++ and python in my bachelor's and master's thesis, and boy you do not want to see the code of some doctorates there. im talking about many 1000 lines of code, not one single class which could have been useful, sometimes not even a single function declared. everything hardcoded, mostly uncommented, and sadly, many many severe mistakes, that caused many problems for my thesis, but not for the doctors thesis, cause it was already done and he got is summa cum laude.

Very frustrating and shocking experience for me, completely knocked me away from university and becoming a doctorate.

If you dropped out of getting a doctorate because you saw some bad code, my dude, I have bad news for you.

There's a reason why it's almost a meme that newly hired programmers at any company propose to rewrite everything because 'the previous guy had no idea what they are doing'.

All code is terrible, undocumented, hardcoded, etc. What matters is that it works. All we can do as engineers is try to leave a codebase in a better place than we found it, but ultimately quality is always going to be compromised by other factors (usually deadlines)

I fully expect to get some backlash from this comment given some of the memes around spaghetti code, but it's true.. you're not going to be in the field very long if you quit after seeing bad code.

about 4 years ago - /u/riotaredherring - Direct link

Originally posted by AWildIndependent

For what it's worth, I agree with everything said here.

Just want to throw it out there that a lot of companies refuse to rewrite old code even though the cost of rewriting the code is far less than the cost of the technical debt it creates over several years.

This is just another example of companies only being able to think in quarters, to their own detriment. To be quite honest, there is never a really good reason to leave shitty code shitty.

The biggest argument is time, but again every single new developer that works on that code base will end up spending more time than necessary trying to even become acclimated into the code base if it is bad enough. Let alone modifying it.

IDK. This is a big pet peeve to me. The entire mindset regarding legacy systems is understandable, but at the same time while being understandable I also think the current approach of most companies is incorrect.

Most of the companies you're referring to are successful, though, and therein lies the rub. Can you make the argument that these companies would be more successful by either rewriting or modifying a system that, from a business perspective, still works? How do you prove that?

The problem with rewriting is that you're proposing that you take a system that works (if imperfect) and suggesting a business invest a lot of time in coming up with a new system that is functionally identical to the old one but is somehow 'better' from a code quality perspective (which may or may not translate to increased value to customers ergo more $$$ for the business).

So, the problem for any engineer proposing a rewrite is how exactly does the rewrite equate to more value for the business and is that worth the time investment? not only would it cost money to pay developers to do this, QA, etc, but it also takes time away from those engineers from doing something that has a more defined value proposition.

This is one of the reasons why you should always aim to incrementally refactor rather than throw something out unless the core underlying assumptions have changed.

Our job as engineers is to make things that work and are relatively maintainable, whether or not the code is artwork is not really relevant to it.

about 4 years ago - /u/riotaredherring - Direct link

Originally posted by AWildIndependent

Wouldn't this mean a rewrite would only occur when the fundamental requirements have changed or a security flaw was found?

I think that's somewhat impractical, but I guess the burden is in the fact that you cannot prove a rewrite would be better until it's already done- which was your point, or at least some of it, I believe.

I think I'm just irritated because I am currently working on a web site (one of many at my company, we bounce around projects) that was done very, very poorly (sizable code base) and makes doing even some of the easiest tasks very difficult and usually quadruples the time it would normally take. This kind of technical debt is where I feel a rewrite is almost mandatory.

Wouldn't this mean a rewrite would only occur when the fundamental requirements

Yes.

There's no need to rewrite everything unless something very fundamental has changed. It's almost always better to refactor instead

security flaw was found?

Security flaws rarely require foundational changes :)

about 4 years ago - /u/riotaredherring - Direct link

Originally posted by AWildIndependent

Security flaws rarely require foundational changes :)

You haven't worked on enough shitty web stacks where people abuse global variables and local storage, I take it?

I'm talking security through obscurity. IDK MAN. I think we have just had vastly different experiences.

I've been working as a software engineer for 7 years. I have worked in mom-and-pop companies, Riot, fintech companies. The entire time I've been using JavaScript as my primary language.

I am also a very active member on codereview.stackexchange.com, /r/webdev, /r/reactjs and stackoverflow.com.

Part of my job involves reviewing any code submitted for security review.

I have seen it all.

There've only been a few times in my life where I thought a full rewrite was mandatory. In nearly every case you can refactor gradually.

about 4 years ago - /u/riotaredherring - Direct link

Originally posted by AWildIndependent

Wouldn't a gradual re-factorization of most of the codebase be effectively the same as a rewrite?

Maybe we have different definitions of what a rewrite is. To me, a rewrite can be in the exact same stack. It seems like, from your responses, that you are taking rewrite to be a fundamental change of how the code works (aka using a different web stack). That's probably the correct definition anyways.

Gradual re-factorization in the same web stack doesn't seem fundamentally different than a rewrite in the same web stack.

My definition of a rewrite is 'We start over from scratch and build the same thing. It might be the same tech stack, but we don't re-use any of the old code.'

A good example of an (IMO, successful, rewrite, despite Reddit memes) would be the League client. The old League client was written in a proprietary stack and in such a way that made it a serious undertaking in order to add new functionality, like replays, which is one of the reasons the client was rewritten.

It wasn't that coding with the old League client was just 'hard'; it was difficult to hire for (proprietary stacks tend to be), difficult to write code in and it made a lot of assumptions about the rest of your tech stack outside of the League client that we in some ways still pay for today.

about 4 years ago - /u/riotaredherring - Direct link

Originally posted by CertainTopic3

So that's why new League website is still bad designed from backend site. Why new articles are visible for public 5 minutes after publication? On your other pages (garena) news appear earlier than on the real page, because they are using real API. I don't understand who came up with the idea of using cron to create static files instead of updating it at the time of publication. I hope someone fix it.

I don't really know much about that specific thing, but I like to call all-in-one replacements Big Bang replacements. Because that's what tends to happen if you try to release a lot of new things at once.

about 4 years ago - /u/riotaredherring - Direct link

Originally posted by CertainTopic3

Unfortunately, this chaos in communication between teams is visible from the outside. Many things are published and left because they work but not necessarily correctly.Things like this with the League website can be reported somewhere or as a normal player, not have a lot of influence to fix it?
I would like something to be done about it, because probably nobody will fix it for the next 10 years.

While I take your feedback on-board, respectfully, I do not think this is a great example of 'chaos in communication between teams': The specific example you mention is a really minor thing that should probably be fixed but isn't as impactful as a lot of other things the teams that own those products could work on.

You're also making a lot of assumptions that we're using cron to publish posts. Perhaps it's just a really slow jenkins job? Or the cache invalidation period is 5 minutes? You get the idea.