Timmy Crawford  4:05 PM
excellent - can you tell me a bit about yourself - like how you got started into the world of programming?

Timofey Kondrashov  4:06 PM
sure, I think my first programming experience was 7th grade when I learned TrueBASIC
I moved between 8th and 9th grade, from maryland to michigan, and I kind of lost my social life and didn't really take to my new high school, and coding was one of my two big pastimes that carried me through that time

Timmy Crawford  4:07 PM
thats so rough to move at that age and adapt

Timofey Kondrashov  4:07 PM
so by the time I started college I was already pretty decent at C++, I did online tutoring for college kids and stuff before I was even enrolled
yeah it wasn't fun
so C++ was my first true love in high school, and I picked up javascript just cause hey, if you want to whip something up and have anyone be able to use it, everyone has a browser!
:100:
1

and armed with C++ and JS basics, I managed to get employed at barracuda where they taught me PHP
didn't end up finishing my degree, but they didn't mind and haven't really had anyone care since (edited)

Timmy Crawford  4:09 PM
very interesting journey there thanks for sharing - so that was barracuda networks?

Timofey Kondrashov  4:09 PM
yeah
:+1:
1


Timmy Crawford  4:10 PM
curious how they used PHP there?

Timofey Kondrashov  4:10 PM
they sell appliances for various security tasks
so the product I worked on, Backup, was just a box that they shipped to customers and it would back up all the data on their network and you could go and retrieve what you needed from the UI
and believe it or not, the firmware for the box was PHP
so the UI for the box had a PHP backend that seamlessly intergrated with all of the code that actually gathers and sends files and stuff for backup (edited)

Timmy Crawford  4:11 PM
fascinating! i knew they sold network appliances - but wasn't aware they were php powered

Timofey Kondrashov  4:11 PM
really weird use case, but gave me an incredibly detailed sort of deep dive into the language
yeah, I don't know if all of them are
no idea about firewall and stuff
but Backup was/is

Timmy Crawford  4:12 PM
oh i bet! we have a backup service here too in our Jetpack product, that is a super challenging problem domain
so what are you looking for in your next job?

Timofey Kondrashov  4:12 PM
stability is kind of my go-to buzzword right now
something longer term, kind of like a destination for the experience I've been gathering
so to me that implies a salary that I can stay at without itching to leave (the ultimate reason I had to leave nexient), and an environment that works for me in human comfort ways, like being able to practice what I know and having power hierarchies that I'm comfortable with
Lulu's was supposed to be that job, but unfortunately the work just wasn't interesting and the team had no plans for growth

Timmy Crawford  4:16 PM
thanks so much for the candid response there, those are some great attributes to look for in a company. automattic has been a great long-term home for me personally... it will be six years for me in May. and i've really enjoyed the journey and haven't gotten bored yet :slightly_smiling_face:

Timofey Kondrashov  4:17 PM
yeah from everything I've read it seems to be a good place to work for what I'm looking for
remote environment is perfect for me since my brain light bulb can turn on at weird hours
:100:
1

and otherwise I like the human attitudes that you advocate for in your creed and elsewhere, I like an empathetic and principled environment

Timmy Crawford  4:18 PM
i really enjoyed the favorite project you shared about creating the chat service in rust - i've heard so many good things about rust it makes me feel like i need to see what all the excitement is about myself! could you share with me a time where you have encountered a challenging performance bug? what steps did you take to diagnose the problem, and what was the eventual fix?

Timofey Kondrashov  4:19 PM
not in Rust specifically, right?

Timmy Crawford  4:19 PM
any project

Timofey Kondrashov  4:19 PM
(but yes, you do need to see what the excitement is about, it's fantastic)

1 reply
Today at 4:20 PMView thread

Timofey Kondrashov  4:19 PM
okay let me think for a sec...
oh I know
I actually ended up writing a SO answer that I was very proud of in regards to this specific problem: https://stackoverflow.com/a/54819633/3648957

Stack OverflowStack Overflow
querySelector and querySelectorAll vs getElementsByClassName and getElementById in JavaScript
I would like to know what exactly is the difference between querySelector and querySelectorAll against getElementsByClassName and getElementById? From this link I could gather that with querySele...
:eyes:
1

but the problem was at Nexient, working with WSI, and the issue was that they had an infinite scroll page that became a performance issue on mobile
so to give an idea, if you go to like https://www.williams-sonoma.com/search/results.html?words=knives

williams-sonoma.comwilliams-sonoma.com
knives | Williams Sonoma
Shop knives from Williams Sonoma. Our expertly crafted collections offer a wide of range of cooking tools and kitchen appliances, including a variety of knives.
idk why but I always searched for "knives" when I was testing their site, maybe that says something about me :knife:
:laughing:
1

but it was a page like that with really dense product descriptions and the feedback we were getting was basically just "things are getting slow and nobody has any idea why"
the atmosphere was kind of of several teams trying to make sure it wasn't THEIR fault, our team included

Timmy Crawford  4:23 PM
little game of performance hot potato :scream:
:potato:
1


Timofey Kondrashov  4:23 PM
but what it turned out the problem was was just that as features kept being added, a lot of them used JS selectors to crawl the page
and this massive infinite scroll had the most elements, and it just so happened that we were reaching a point where all of the JS selectors were slowing down the page enough that it was blocking rendering for some users
my assumption being that the selectors were taking cumulatively more than one render cycle (1/60th of a second I assume, though I don't know/remember how chrome works for this)
the answer I wrote related to the fact that by cutting querySelectors and using more getElement calls, you could actually make monster gains in performance, because getElement calls use some kind of hashing mechanism internally to achieve constant time lookup by selector
whereas querySelector does this silly linear iteration through the DOM to find the elements that match the selector

Timmy Crawford  4:26 PM
interesting - any variance at all by browser in that behavior?

Timofey Kondrashov  4:26 PM
honestly the approach was mostly just "what the HECK is going on" for a while, and it was mostly a matter of trying to understand why THAT page
I think it was mostly by device, not by browser
I do not remember now though

Timofey Kondrashov  4:27 PM
we could never reproduce it in house, cause we all had souped up machines and phones

1 reply
Today at 4:28 PMView thread

Timofey Kondrashov  4:27 PM
but people at WSI were consistently getting issues on their phones in one release that hadn't happened in previous releases

Timmy Crawford  4:28 PM
really great story there - did the team adopt any changes about usage of querySelector? or maybe implement some performance tooling to see when certain code changes resulted in perf hits?

Timofey Kondrashov  4:29 PM
our team ended up kind of shouldering the work and just finding as many instances as we could fix, I think we identified several that were doing querySelector in an onScroll event
we did make a general recommendation in our SPA guide to prefer getElement, but we fixed it just by finding the ones that were blocking the renders

Timmy Crawford  4:31 PM
isn't it amazing how performance isn't the #1 "feature" teams focus on delivering?
especially in ecommerce where it is super critical

Timofey Kondrashov  4:31 PM
I think the way that web works is really interesting in regards to that
because I think it's informed in large part by what we just talked about - souped up machine developers
I see that with facebook's Messenger on a daily basis, though they're rewriting it now
but it seems like there's this assumption that's correct until it's not, which is that web is about UI, not performance!

Timmy Crawford  4:32 PM
i also feel the draw to ship/iterate quickly leads to performance being an afterthought also

Timofey Kondrashov  4:32 PM
and then when you run into performance issues it's going to be on a phone that nobody in your building has before it's on any of your things
yeah
but it's hard to place it as the first priority when there's so many other cool things you can put in your app, like buttons and infinite scrolls and whatever

Timmy Crawford  4:33 PM
but yep the obscure device perf bugs, or even perf issues on iOS ( Mobile Safari :oldmanyellsatcloud: ) that can only be reproduced on a physical device vs an emulator
:oldmanyellsatcloud:
1


Timofey Kondrashov  4:34 PM
I love doing performance-first work but I think my time as WSI was the only time it was prioritized

Timmy Crawford  4:34 PM
well thanks again for that story, and that is a very great answer on SO as well :thumbup:

Timofey Kondrashov  4:34 PM
and only because things blew up
sure! I'm glad you asked something I had a lot to say on haha

Timmy Crawford  4:34 PM
can you give me an example of a time when you were working with a legacy application? how did you approach it? what did you learn?

Timofey Kondrashov  4:35 PM
hahah I could give the same example really, but luckily I've done that nearly everywhere
any application that's in production is already legacy in a sense, no? :stuck_out_tongue:
barracuda was my most educational run-in with truly legacy code
Backup started as an independent startup and was acquired by Barracuda, and they still had some of the original devs' code in there
I remember distinctly a file where all of the variable names were superheros
so it was like batman = blah
superman = something else

Timmy Crawford  4:36 PM
YES!!!

Timofey Kondrashov  4:36 PM
batman * superman / spiderman = something else

Timmy Crawford  4:36 PM
this sounds like a true legacy app

Timofey Kondrashov  4:36 PM
it was as legacy as they come
my instinct as a brand new junior developer was "I'm going to rewrite all of this right now"
and I guess the educational bit was in learning how to weigh the benefits of having a clean codebase with the time lost
from a business perspective, the time loss makes sense, since it's the same idea of why fix things when you can push features ($$$$$$$)
but more interesting from a developer perspective is how the time loss can either be recouped later or not
so taking the spiderman file as an example, it just was never changed
it worked, it had always worked, nobody needed to look at it
so is refactoring it to make it "correct" actually the "correct" move? now, I'd probably say no
but when I had to go in somewhere and actually make a change, and i couldn't read it, that's when I'd refactor the whole file
and I stick to that process even now, if I need to change legacy code, then my needle starts really pointing at the need to refactor that section
but it becomes much more targeted
than just "let's rewrite the whole thing"

Timmy Crawford  4:40 PM
did this super hero backup app have any test coverage at all to help?

Timofey Kondrashov  4:40 PM
not even a little bit :stuck_out_tongue:

Timmy Crawford  4:40 PM
indeed, a true legacy legend

Timofey Kondrashov  4:41 PM
I don't remember what it did, I think it was a utility script so it might have sat a little outside the main codebase
but we didn't write tests at all at barracuda then

Timmy Crawford  4:42 PM
thanks so much for that story too - sounds like a good approach was taken when working with that project! can you tell me about a time where you have used an automated test suite? what did you test? and how did it benefit you or your team?

Timofey Kondrashov  4:43 PM
williams-sonoma also did probably the heaviest testing of the projects I've been on, I don't remember exactly what frameworks they used cause they all just read like english to me, but they had both unit tests and automated UI tests
and I think a bunch of automated tests that weren't quite unit tests for their Java too, though I never touched the Java code really
I've always felt that user testing is incredibly valuable to developers, but as a developer it doesn't make a difference to me if it's automated or a competent QA team doing it
I'd say much more so than unit testing, I've always relied on QA feedback to improve the way that I code, kind of paradoxically since they don't generally look at the code
but unit testing is extremely handy for piece of mind
the TDD flow is very satisfying in its own way
you're just making red things go away, feels like you don't have to really think too hard

Timmy Crawford  4:47 PM
thanks for the detailed response there - i really enjoy watching user/usability tests too - i often refer to it as "empathy" driven development. totally a great thing for developers to get to see how users interact with the tools they build
What’s your ideal production deployment setup for a web application? Any thoughts on release cycles?

Timofey Kondrashov  4:48 PM
if I were starting my own company and I expected it to be big and I wanted to do it right the first time, I'd use docker/kubernetes for what I see as the hard part
I've never really used them personally, but if you have CI in your repo with tests and everything you can just set up your release branches to deploy with whatever tools, and kubernetes takes care of the scaling
release cycles... yes I have thoughts, but I don't think I have extremely strong opinions
:+1:
1

I think the closer you get to continuously releasing the better
but there's also obvious cons to not having MASSIVE INCREDIBLY-WELL TESTED RELEASES (tm)
it really depends on what your application is, I wouldn't do continuous releases for bank backend software probably

Timmy Crawford  4:52 PM
even in the MASSIVE INCREDIBLY-WELL TESTED RELEASES (tm) - there will still be bugs

Timofey Kondrashov  4:52 PM
yeah

Timmy Crawford  4:52 PM
cool, thanks again for the response there
so definitely sounds like you are a fan of Rust - what are your thoughts on PHP?

Timofey Kondrashov  4:53 PM
quick final thought on the last question: as a developer, I definitely prefer having my code be in production ASAP because I don't have to babysit it through the whole cycle
:+1:
1

PHP is excellent, but it wasn't when I used it :stuck_out_tongue:
PHP like... 5.7 was it? that added typing
I might have that number completely wrong

Timmy Crawford  4:53 PM
i don't know off the top of my head

Timofey Kondrashov  4:54 PM
basically I think it just keeps getting better, I haven't followed the ecosystem for a while but when I did it seemed like the devs really understood what the modernization of the language should be like
I really don't think of it much differently than C++ anymore, they've both done a great job of adapting to the modern world, typed C-style languages
except of course PHP makes the most sense for web
and when you don't need compiled language speeds
:+1:
1

but I like reading PHP, I love the docs, I love having top-level language constructs for common things

Timmy Crawford  4:56 PM
thanks for the response there - it really has come a long ways from when i first started using it too!
can you tell me about a time when you had to make a trade-off between user experience, and an optimal technical design choice?

Timofey Kondrashov  4:56 PM
hahaha
margin: 1px; comes to mind
:laughing:
1

noooooooo my code!
but there's probably better examples
hm, this probably counts, but when they did make us the performance team (again at WSI) there was a question that came up of loading the components of the page on first load (edited)
so the question was basically, do you want the side nav, search, page content, or whatever else to load first
I think the tradeoffs there were mostly a result of somewhat poor communication, but it's also a space with no right answer
because different users are visiting the page for different reasons
5:00
if you're waiting for the page to load, you don't care if the nav is working, you can't even see it
5:00
but if you just want to get to the knives ASAP, then what good is the homepage doing you
5:01
the "optimal technical design" choice is just to throw everything in a compressed file
5:01
and then when you get it, you get it
5:01
clean code, lowest bandwidth, fewest requests
5:02
but you can really complicate the code to benefit certain users by giving them the features they're waiting for up front
5:02
which we chose to do :slightly_smiling_face:

Timmy Crawford  5:02 PM
absolutely, it is quite a balancing act at times
5:02
okay one last question from my side of things, then i will pass the :microphone: to you
5:03
tell me about a time when you’ve employed a programming design pattern recently, what made you choose the pattern? what trade-offs did you encounter?

Timofey Kondrashov  5:04 PM
generally, I'd say every time I choose a design pattern it's more like wandering into a space where the pattern seems like an obvious choice
:+1:
1

5:04
there's a link I wanna find real quick

Timmy Crawford  5:04 PM
sure take your time

Timofey Kondrashov  5:05 PM
https://caseymuratori.com/blog_0015

caseymuratori.com
Semantic Compression
An introduction to the idea that code should be approached with a mindset towards compressing it semantically, rather than orienting it around objects.
5:05
this isn't going to be my whole answer but I'm also basically just going to say what he does
5:06
which is that design patterns stem from a sort of simple algorithm where you continually try to clean up your code, and eventually you find that to make your code cleaner, there's a pattern that fits
5:06
I don't agree with picking a pattern until you have some code on the screen already, but the design pattern that I end up in the most often is just OOP

Timmy Crawford  5:06 PM
will definitely have to give that post a read, thanks for the link :bow:

Timofey Kondrashov  5:06 PM
which I guess encompasses a trillion design patterns in itself
5:07
but for example, I'm writing some chess AI stuff now (rust chat took a back seat for a bit) and I find that I'm going to have a policy and an evaluation model
5:08
without going into too much detail, policy picks a move, evaluation tells you if you a position on the board is good for you
5:08
but they're both ML models
5:08
so what do they get? a parent Model class!
5:08
but it's not until I've already written some code and seen, aha, I'm calling policy.train and evaluation.train
5:08
it makes sense for there to be a model.train that they extend
5:08
that I'll reach out and jam that pattern into place

Timmy Crawford  5:09 PM
thanks again for the detailed response - sounds like another fun project there!

Timofey Kondrashov  5:09 PM
another example that comes to mind as of late is functional JS
5:09
like map/filter/reduce vs for loops
5:10
and that's another space where I just write some code
5:10
and then I'll pick the one that really makes the code make sense
5:10
reduce loops tend to be much harder to understand if you're not used to them, but for loops for things that can be done with .reduce can be way more complex

Timmy Crawford  5:11 PM
readable code is a wonderful thing

Timofey Kondrashov  5:11 PM
so I'll write the code, and bend it one way or the other a bit until I see which pattern fits best
5:11
the value of patterns is in that a lot of people know them, so it makes your code easy to read
5:12
so it makes sense 1) to avoid patterns if the code can be understood without them 2) to use patterns to make your code legible if it can't easily be understood
5:12
and yeah, readability is kind of my #1 thing
5:13
not ideologically, I just think it's really fun to edit style
5:13
:stuck_out_tongue:

Timmy Crawford  5:13 PM
alright, well thanks again for all the answers to my questions today, much appreciated. as promised i'd be delighted to answer any questions you have now