G2A Many GEOs
SHARE
TWEET

Untitled

a guest Mar 31st, 2020 78 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. Timmy Crawford  4:05 PM
  2. excellent - can you tell me a bit about yourself - like how you got started into the world of programming?
  3.  
  4. Timofey Kondrashov  4:06 PM
  5. sure, I think my first programming experience was 7th grade when I learned TrueBASIC
  6. 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
  7.  
  8. Timmy Crawford  4:07 PM
  9. thats so rough to move at that age and adapt
  10.  
  11. Timofey Kondrashov  4:07 PM
  12. 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
  13. yeah it wasn't fun
  14. 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!
  15. :100:
  16. 1
  17.  
  18. and armed with C++ and JS basics, I managed to get employed at barracuda where they taught me PHP
  19. didn't end up finishing my degree, but they didn't mind and haven't really had anyone care since (edited)
  20.  
  21. Timmy Crawford  4:09 PM
  22. very interesting journey there thanks for sharing - so that was barracuda networks?
  23.  
  24. Timofey Kondrashov  4:09 PM
  25. yeah
  26. :+1:
  27. 1
  28.  
  29.  
  30. Timmy Crawford  4:10 PM
  31. curious how they used PHP there?
  32.  
  33. Timofey Kondrashov  4:10 PM
  34. they sell appliances for various security tasks
  35. 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
  36. and believe it or not, the firmware for the box was PHP
  37. 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)
  38.  
  39. Timmy Crawford  4:11 PM
  40. fascinating! i knew they sold network appliances - but wasn't aware they were php powered
  41.  
  42. Timofey Kondrashov  4:11 PM
  43. really weird use case, but gave me an incredibly detailed sort of deep dive into the language
  44. yeah, I don't know if all of them are
  45. no idea about firewall and stuff
  46. but Backup was/is
  47.  
  48. Timmy Crawford  4:12 PM
  49. oh i bet! we have a backup service here too in our Jetpack product, that is a super challenging problem domain
  50. so what are you looking for in your next job?
  51.  
  52. Timofey Kondrashov  4:12 PM
  53. stability is kind of my go-to buzzword right now
  54. something longer term, kind of like a destination for the experience I've been gathering
  55. 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
  56. Lulu's was supposed to be that job, but unfortunately the work just wasn't interesting and the team had no plans for growth
  57.  
  58. Timmy Crawford  4:16 PM
  59. 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:
  60.  
  61. Timofey Kondrashov  4:17 PM
  62. yeah from everything I've read it seems to be a good place to work for what I'm looking for
  63. remote environment is perfect for me since my brain light bulb can turn on at weird hours
  64. :100:
  65. 1
  66.  
  67. and otherwise I like the human attitudes that you advocate for in your creed and elsewhere, I like an empathetic and principled environment
  68.  
  69. Timmy Crawford  4:18 PM
  70. 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?
  71.  
  72. Timofey Kondrashov  4:19 PM
  73. not in Rust specifically, right?
  74.  
  75. Timmy Crawford  4:19 PM
  76. any project
  77.  
  78. Timofey Kondrashov  4:19 PM
  79. (but yes, you do need to see what the excitement is about, it's fantastic)
  80.  
  81. 1 reply
  82. Today at 4:20 PMView thread
  83.  
  84. Timofey Kondrashov  4:19 PM
  85. okay let me think for a sec...
  86. oh I know
  87. 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
  88.  
  89. Stack OverflowStack Overflow
  90. querySelector and querySelectorAll vs getElementsByClassName and getElementById in JavaScript
  91. 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...
  92. :eyes:
  93. 1
  94.  
  95. 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
  96. so to give an idea, if you go to like https://www.williams-sonoma.com/search/results.html?words=knives
  97.  
  98. williams-sonoma.comwilliams-sonoma.com
  99. knives | Williams Sonoma
  100. 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.
  101. idk why but I always searched for "knives" when I was testing their site, maybe that says something about me :knife:
  102. :laughing:
  103. 1
  104.  
  105. 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"
  106. the atmosphere was kind of of several teams trying to make sure it wasn't THEIR fault, our team included
  107.  
  108. Timmy Crawford  4:23 PM
  109. little game of performance hot potato :scream:
  110. :potato:
  111. 1
  112.  
  113.  
  114. Timofey Kondrashov  4:23 PM
  115. 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
  116. 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
  117. 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)
  118. 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
  119. whereas querySelector does this silly linear iteration through the DOM to find the elements that match the selector
  120.  
  121. Timmy Crawford  4:26 PM
  122. interesting - any variance at all by browser in that behavior?
  123.  
  124. Timofey Kondrashov  4:26 PM
  125. 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
  126. I think it was mostly by device, not by browser
  127. I do not remember now though
  128.  
  129. Timofey Kondrashov  4:27 PM
  130. we could never reproduce it in house, cause we all had souped up machines and phones
  131.  
  132. 1 reply
  133. Today at 4:28 PMView thread
  134.  
  135. Timofey Kondrashov  4:27 PM
  136. but people at WSI were consistently getting issues on their phones in one release that hadn't happened in previous releases
  137.  
  138. Timmy Crawford  4:28 PM
  139. 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?
  140.  
  141. Timofey Kondrashov  4:29 PM
  142. 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
  143. 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
  144.  
  145. Timmy Crawford  4:31 PM
  146. isn't it amazing how performance isn't the #1 "feature" teams focus on delivering?
  147. especially in ecommerce where it is super critical
  148.  
  149. Timofey Kondrashov  4:31 PM
  150. I think the way that web works is really interesting in regards to that
  151. because I think it's informed in large part by what we just talked about - souped up machine developers
  152. I see that with facebook's Messenger on a daily basis, though they're rewriting it now
  153. but it seems like there's this assumption that's correct until it's not, which is that web is about UI, not performance!
  154.  
  155. Timmy Crawford  4:32 PM
  156. i also feel the draw to ship/iterate quickly leads to performance being an afterthought also
  157.  
  158. Timofey Kondrashov  4:32 PM
  159. 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
  160. yeah
  161. 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
  162.  
  163. Timmy Crawford  4:33 PM
  164. 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
  165. :oldmanyellsatcloud:
  166. 1
  167.  
  168.  
  169. Timofey Kondrashov  4:34 PM
  170. I love doing performance-first work but I think my time as WSI was the only time it was prioritized
  171.  
  172. Timmy Crawford  4:34 PM
  173. well thanks again for that story, and that is a very great answer on SO as well :thumbup:
  174.  
  175. Timofey Kondrashov  4:34 PM
  176. and only because things blew up
  177. sure! I'm glad you asked something I had a lot to say on haha
  178.  
  179. Timmy Crawford  4:34 PM
  180. 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?
  181.  
  182. Timofey Kondrashov  4:35 PM
  183. hahah I could give the same example really, but luckily I've done that nearly everywhere
  184. any application that's in production is already legacy in a sense, no? :stuck_out_tongue:
  185. barracuda was my most educational run-in with truly legacy code
  186. Backup started as an independent startup and was acquired by Barracuda, and they still had some of the original devs' code in there
  187. I remember distinctly a file where all of the variable names were superheros
  188. so it was like batman = blah
  189. superman = something else
  190.  
  191. Timmy Crawford  4:36 PM
  192. YES!!!
  193.  
  194. Timofey Kondrashov  4:36 PM
  195. batman * superman / spiderman = something else
  196.  
  197. Timmy Crawford  4:36 PM
  198. this sounds like a true legacy app
  199.  
  200. Timofey Kondrashov  4:36 PM
  201. it was as legacy as they come
  202. my instinct as a brand new junior developer was "I'm going to rewrite all of this right now"
  203. and I guess the educational bit was in learning how to weigh the benefits of having a clean codebase with the time lost
  204. from a business perspective, the time loss makes sense, since it's the same idea of why fix things when you can push features ($$$$$$$)
  205. but more interesting from a developer perspective is how the time loss can either be recouped later or not
  206. so taking the spiderman file as an example, it just was never changed
  207. it worked, it had always worked, nobody needed to look at it
  208. so is refactoring it to make it "correct" actually the "correct" move? now, I'd probably say no
  209. 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
  210. 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
  211. but it becomes much more targeted
  212. than just "let's rewrite the whole thing"
  213.  
  214. Timmy Crawford  4:40 PM
  215. did this super hero backup app have any test coverage at all to help?
  216.  
  217. Timofey Kondrashov  4:40 PM
  218. not even a little bit :stuck_out_tongue:
  219.  
  220. Timmy Crawford  4:40 PM
  221. indeed, a true legacy legend
  222.  
  223. Timofey Kondrashov  4:41 PM
  224. 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
  225. but we didn't write tests at all at barracuda then
  226.  
  227. Timmy Crawford  4:42 PM
  228. 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?
  229.  
  230. Timofey Kondrashov  4:43 PM
  231. 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
  232. 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
  233. 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
  234. 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
  235. but unit testing is extremely handy for piece of mind
  236. the TDD flow is very satisfying in its own way
  237. you're just making red things go away, feels like you don't have to really think too hard
  238.  
  239. Timmy Crawford  4:47 PM
  240. 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
  241. What’s your ideal production deployment setup for a web application? Any thoughts on release cycles?
  242.  
  243. Timofey Kondrashov  4:48 PM
  244. 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
  245. 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
  246. release cycles... yes I have thoughts, but I don't think I have extremely strong opinions
  247. :+1:
  248. 1
  249.  
  250. I think the closer you get to continuously releasing the better
  251. but there's also obvious cons to not having MASSIVE INCREDIBLY-WELL TESTED RELEASES (tm)
  252. it really depends on what your application is, I wouldn't do continuous releases for bank backend software probably
  253.  
  254. Timmy Crawford  4:52 PM
  255. even in the MASSIVE INCREDIBLY-WELL TESTED RELEASES (tm) - there will still be bugs
  256.  
  257. Timofey Kondrashov  4:52 PM
  258. yeah
  259.  
  260. Timmy Crawford  4:52 PM
  261. cool, thanks again for the response there
  262. so definitely sounds like you are a fan of Rust - what are your thoughts on PHP?
  263.  
  264. Timofey Kondrashov  4:53 PM
  265. 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
  266. :+1:
  267. 1
  268.  
  269. PHP is excellent, but it wasn't when I used it :stuck_out_tongue:
  270. PHP like... 5.7 was it? that added typing
  271. I might have that number completely wrong
  272.  
  273. Timmy Crawford  4:53 PM
  274. i don't know off the top of my head
  275.  
  276. Timofey Kondrashov  4:54 PM
  277. 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
  278. 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
  279. except of course PHP makes the most sense for web
  280. and when you don't need compiled language speeds
  281. :+1:
  282. 1
  283.  
  284. but I like reading PHP, I love the docs, I love having top-level language constructs for common things
  285.  
  286. Timmy Crawford  4:56 PM
  287. thanks for the response there - it really has come a long ways from when i first started using it too!
  288. can you tell me about a time when you had to make a trade-off between user experience, and an optimal technical design choice?
  289.  
  290. Timofey Kondrashov  4:56 PM
  291. hahaha
  292. margin: 1px; comes to mind
  293. :laughing:
  294. 1
  295.  
  296. noooooooo my code!
  297. but there's probably better examples
  298. 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)
  299. so the question was basically, do you want the side nav, search, page content, or whatever else to load first
  300. I think the tradeoffs there were mostly a result of somewhat poor communication, but it's also a space with no right answer
  301. because different users are visiting the page for different reasons
  302. 5:00
  303. if you're waiting for the page to load, you don't care if the nav is working, you can't even see it
  304. 5:00
  305. but if you just want to get to the knives ASAP, then what good is the homepage doing you
  306. 5:01
  307. the "optimal technical design" choice is just to throw everything in a compressed file
  308. 5:01
  309. and then when you get it, you get it
  310. 5:01
  311. clean code, lowest bandwidth, fewest requests
  312. 5:02
  313. but you can really complicate the code to benefit certain users by giving them the features they're waiting for up front
  314. 5:02
  315. which we chose to do :slightly_smiling_face:
  316.  
  317. Timmy Crawford  5:02 PM
  318. absolutely, it is quite a balancing act at times
  319. 5:02
  320. okay one last question from my side of things, then i will pass the :microphone: to you
  321. 5:03
  322. 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?
  323.  
  324. Timofey Kondrashov  5:04 PM
  325. 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
  326. :+1:
  327. 1
  328.  
  329. 5:04
  330. there's a link I wanna find real quick
  331.  
  332. Timmy Crawford  5:04 PM
  333. sure take your time
  334.  
  335. Timofey Kondrashov  5:05 PM
  336. https://caseymuratori.com/blog_0015
  337.  
  338. caseymuratori.com
  339. Semantic Compression
  340. An introduction to the idea that code should be approached with a mindset towards compressing it semantically, rather than orienting it around objects.
  341. 5:05
  342. this isn't going to be my whole answer but I'm also basically just going to say what he does
  343. 5:06
  344. 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
  345. 5:06
  346. 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
  347.  
  348. Timmy Crawford  5:06 PM
  349. will definitely have to give that post a read, thanks for the link :bow:
  350.  
  351. Timofey Kondrashov  5:06 PM
  352. which I guess encompasses a trillion design patterns in itself
  353. 5:07
  354. 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
  355. 5:08
  356. without going into too much detail, policy picks a move, evaluation tells you if you a position on the board is good for you
  357. 5:08
  358. but they're both ML models
  359. 5:08
  360. so what do they get? a parent Model class!
  361. 5:08
  362. but it's not until I've already written some code and seen, aha, I'm calling policy.train and evaluation.train
  363. 5:08
  364. it makes sense for there to be a model.train that they extend
  365. 5:08
  366. that I'll reach out and jam that pattern into place
  367.  
  368. Timmy Crawford  5:09 PM
  369. thanks again for the detailed response - sounds like another fun project there!
  370.  
  371. Timofey Kondrashov  5:09 PM
  372. another example that comes to mind as of late is functional JS
  373. 5:09
  374. like map/filter/reduce vs for loops
  375. 5:10
  376. and that's another space where I just write some code
  377. 5:10
  378. and then I'll pick the one that really makes the code make sense
  379. 5:10
  380. 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
  381.  
  382. Timmy Crawford  5:11 PM
  383. readable code is a wonderful thing
  384.  
  385. Timofey Kondrashov  5:11 PM
  386. so I'll write the code, and bend it one way or the other a bit until I see which pattern fits best
  387. 5:11
  388. the value of patterns is in that a lot of people know them, so it makes your code easy to read
  389. 5:12
  390. 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
  391. 5:12
  392. and yeah, readability is kind of my #1 thing
  393. 5:13
  394. not ideologically, I just think it's really fun to edit style
  395. 5:13
  396. :stuck_out_tongue:
  397.  
  398. Timmy Crawford  5:13 PM
  399. 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
RAW Paste Data
Ledger Nano X - The secure hardware wallet
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand
Top