1. 3

    if you enjoyed this, I highly recommend the fantastic technical/process log here: https://www.youtube.com/watch?v=hTlNVUmBA28

    1. 1

      I found myself in this position a lot at work, and wrote a post about to be useful when you’re in the junior developer tasked with reviewing code from people who know the system better than you do - because it can be intimidating and difficult!!

      https://maxbittker.github.io/code-review/

      1. 3

        map and filter capture common operations in a really solid way that is almost always an advantage over a loop.

        In my experience, the bar is a lot higher when considering rewriting loops into reduces. A reduce isn’t necessarily much more opinionated or explicit than a loop, and so you need to be careful to ensure that you’re choosing it over a loop for the right reasons.

        If your reducer body is longer than a single statement, or your output data structure is more complicated than a single literal, you might not be gaining much by using reduce.

        1. 3

          https://redash.io/ Redash is a very similar feature set (if I understand correctly) and is open source, if anyone wants something hostable / ownable.

          1. 1

            (disclaimer: Redash author)

            Thank you for mentioning Redash. Actually Redash’s features extend beyond QueryClips, as it allows to visualize the data, create dashboards, alerts and more.

            @dpaola2 on the website you mentioned that you created QueryClips after being frustrated with the lack of simple, easy-to-use tools. I created Redash for the same reasons ;-) I just wonder, did you have the chance to evaluate Redash before creating QueryClips? :-)

          1. 5

            Working on a game in webgl, and packaging some tiny quality of life tools for my workflow in the meantime. main takeaways are that regl and glslify are really delightful!

            A mystery for the reader: What is this weird rendering artifact i’m getting on mobile? image

            At work this morning, fixing a small crop of bugs that popped up over weekend <3

            1. 25

              I used to do the things listed in this article, but very recently I’ve changed my mind.

              The answer to reviewing code you don’t understand is you say “I don’t understand this” and you send it back until the author makes you understand in the code.

              I’ve experienced too much pain from essentially rubber-stamping with a “I don’t understand this. I guess you know what you’re doing.” And then again. And again. And then I have to go and maintain that code and, guess what, I don’t understand it. I can’t fix it. I either have to have the original author help me, or I have to throw it out. This is not how a software engineering team can work in the long-term.

              More succinctly: any software engineering team is upper-bound architecturally by the single strongest team member (you only need one person to get the design right) and upper-bound code-wise by the single weakest/least experience team member. If you can’t understand the code now, you can bet dollars to donuts that any new team member or new hire isn’t going to either (the whole team must be able to read the code because you don’t know what the team churn is going to be). And that’s poison to your development velocity. The big mistake people make in code review is to think the team is bound by the strongest team member code-wise too and defer to their experience, rather than digging in their heels and say “I don’t understand this.”

              The solution to “I don’t understand this” is plain old code health. More functions with better names. More tests. Smaller diffs to review. Comments about the edge cases and gotchas that are being worked around but you wouldn’t know about. Not thinking that the code review is the place to convince the reviewer to accept the commit because no-one will ever go back to the review if they don’t understand the code as an artifact that stands by itself. If you don’t understand it as a reviewer in less than 5 minutes, you punt it back and say “You gotta do this better.” And that’s hard. It’s a hard thing to say. I’m beginning to come into conflict about it with other team members who are used to getting their ungrokkable code rubber stamped.

              But code that isn’t understandable is a failure of the author, not the reviewer.

              1. 7

                More succinctly: any software engineering team is upper-bound architecturally by the single strongest team member (you only need one person to get the design right) and upper-bound code-wise by the single weakest/least experience team member.

                Well put – hearing you type that out loud makes it incredibly apparent.

                Anywhoo, I think your conclusion isn’t unreasonable (sometimes you gotta be the jerk) but the real problem is upstream. It’s a huge waste when bad code makes it all the way to review and then and then needs to be written again; much better would be to head it off at the pass. Pairing up the weaker / more junior software engineers with the more experienced works well, but is easier said than done.

                1. 4

                  hmm, you make a good point and I don’t disagree. Do you think the mandate on the author to write understandable code becomes weaker when the confusing part is the domain, and not the code itself? (Although I do acknowledge that expressive, well-structured and well-commented code should strive to bring complicated aspects of the problem domain into the picture, and not leave it up to assumed understanding.)

                  1. 3

                    I think your point is very much applicable. Sometimes it takes a very long time to fully understand the domain, and until you do, the code will suffer. But you have competing interests. For example, at some point, you need to ship something.

                    1. 2

                      Do you think the mandate on the author to write understandable code becomes weaker when the confusing part is the domain, and not the code itself?

                      That’s a good question.

                      In the very day-to-day, I don’t personally find that code reviews have a problem from the domain level. Usually I would expect/hope that there’s a design doc, or package doc, or something, that explains things. I don’t think we should expect software engineers to know how a carburetor works in order to create models for a car company, the onus is on the car company to provide the means to find out how the carburetor works.

                      I think it gets much tricker when the domain is actually computer science based, as we kind of just all resolved that there are people that know how networks work and they write networking code, and there’s people who know how kernels work and they write kernel code etc etc. We don’t take the time to do the training and assume if someone wants to know about it, they’ll learn themselves. But in that instance, I would hope the reviewer is also a domain expert, but on small teams that probably isn’t viable.

                      And like @burntsushi said, you gotta ship sometimes and trust people. But I think the pressure eases as the company grows.

                      1. 1

                        That makes sense. I think you’ve surfaced an assumption baked into the article which I wasn’t aware of, having only worked at small companies with lots of surface area. But I see how it comes across as particularly troublesome advice outside of that context

                    2. 4

                      I’m beginning to come into conflict about it with other team members

                      How do you resolve those conflicts? In my experience, everyone who opens a PR review finds their code to be obvious and self-documenting. It’s not uncommon to meet developers lacking the self-awareness required to improve their code along the lines of your objections. For those developers, I usually focus on quantifiable metrics like “it doesn’t break anything”, “it’s performant”, and “it does what it’s meant to do”. Submitting feedback about code quality often seems to regress to a debate over first principles. The result is that you burn social capital with the entire team, especially when working on teams without a junior-senior hierarchy, where no one is a clear authority.

                      1. 2

                        Not well. I don’t have a good answer for you. If someone knows, tell me how. If I knew how to simply resolve the conflicts I would. My hope is that after a while the entire team begins to internalize writing for the lowest common denominator, and it just happens and/or the team backs up the reviewer when there is further conflict.

                        But that’s a hope.

                        1. 2

                          t’s not uncommon to meet developers lacking the self-awareness required to improve their code along the lines of your objections. For those developers, I usually focus on quantifiable metrics like “it doesn’t break anything”, “it’s performant”, and “it does what it’s meant to do”. Submitting feedback about code quality often seems to regress to a debate over first principles.

                          Require sign-off from at least one other developer before they can merge, and don’t budge on it – readability and understandability are the most important issues. In 5 years people will give precisely no shits that it ran fast 5 years ago, and 100% care that the code can be read and modified by usually completely different authors to meet changing business needs. It requires a culture shift. You may well need to remove intransigent developers to establish a healthier culture.

                          The result is that you burn social capital with the entire team, especially when working on teams without a junior-senior hierarchy, where no one is a clear authority.

                          This is a bit beyond the topic at hand, but I’ve never had a good experience in that kind of environment. If the buck doesn’t stop somewhere, you end up burning a lot of time arguing and the end result is often very muddled code. Even if it’s completely arbitrary, for a given project somebody should have a final say.

                          1. 1

                            The result is that you burn social capital with the entire team, especially when working on teams without a junior-senior hierarchy, where no one is a clear authority.

                            This is a bit beyond the topic at hand, but I’ve never had a good experience in that kind of environment. If the buck doesn’t stop somewhere, you end up burning a lot of time arguing and the end result is often very muddled code. Even if it’s completely arbitrary, for a given project somebody should have a final say.

                            I’m not sure.

                            At very least, when no agreement is found, the authorities should document very carefully and clearly why they did take a certain decision. When this happens everything goes smooth.

                            In a few cases, I saw a really seasoned authority to change his mind while writing down this kind of document, and finally to choose the most junior dev proposal. And I’ve also seen a younger authority faking a LARGE project just because he took any objection as a personal attack. When the doom came (with literally hundreds of thousands euros wasted) he kindly left the company.

                            Also I’ve seen a team of 5 people working very well for a few years together despite daily debates. All the debates were respectful and technically rooted. I was junior back then, but my opinions were treated on pars with more senior colleagues. And we were always looking for syntheses, not compromises.

                        2. 2

                          I agree with the sentiment to an extent, but there’s something to be said for learning a language or domain’s idioms, and honestly some things just aren’t obvious at first sight.

                          There’s “ungrokkable” code as you put it (god knows i’ve written my share of that) but there’s also code you don’t understand because you have had less exposure to certain idioms, so at first glance it is ungrokkable, until it no longer is.

                          If the reviewer doesn’t know how to map over an array, no amount of them telling me they doesn’t understand will make me push to a new array inside a for-loop. I would rather spend the time sitting down with people and trying to level everyone up.

                          To give a concrete personal example, there are still plenty of usages of spreading and de-structuring in JavaScript that trip me up when i read them quickly. But i’ll build up a tolerance to it, and soon they won’t.

                        1. 10

                          I ended up writing a ClojureScript micro-framework for Node called Macchiato. I primarily work with Clojure, and I found a few cases where the JVM is not the best fit. The two main limitations being relatively high memory requirements and startup time. This makes the JVM a poor fit for things like AWS Lambda. I had a use case for making some lightweight services at work, and wanted to learn a bit about the Node ecosystem, so this was the result.

                          1. 2

                            Very excited about new developments like shadow-cljs and macchiato in the clojurescript world! thanks Yogthos :)

                            1. 1

                              Thanks, 2018 should be a pretty exciting year for ClojureScript. :)

                          1. 3

                            A twitter bot that brings me small amounts of joy in semi-regular intervals: @NYT_first_said

                            It’s nice having code running that you can interact with every day, lends itself to lots of tiny improvements.

                            I also made a lot of visual code sketches, and honed my tooling and process for iterating and version controlling them! I hope to expand on these tools and make them useful for outside consumption this year.

                            https://maxbittker.com/ Built a site, went very slightly overboard, and listed some art and blog posts on it!

                            Working on an open source product (Sentry) was also really fun! Looking forward to 2018 there.

                            1. 1

                              bravo! for clarification, when they say

                              Each pair of samples from the sound file interpreted as 2D point.

                              do they mean simply the intensities of two consecutive pairs of scalars, x & y being left and right channels?

                              1. 1

                                yes, the channels are connected to x and y respectively. this page has more detail on how oscilloscope visualisations for music work.

                              1. 6

                                in berlin making hanging out and making art! starting with fragment shading webcam inputs https://maxbittker.github.io/webcam-sketches/ also blogging this week: https://maxbittker.com/rc-art-pop-up/

                                1. 6

                                  Happy to see people writing screensavers. In many ways, they’ve outlived their namesake purpose, but there is still something so charming about them! I also recently wrote a mac os screen saver (for my first time) and unfortunately found that the fragment shader I wrote really heats up my machine.

                                  1. 3

                                    They’re possibly still useful on display types that burn in in the modern day like OLED - and for people still on plasma and god forbid, CRTs, they still have a use.

                                    1. 6

                                      Is a screen saver better than just turning the monitor off (i.e. turning turning monitor output off which makes the screen go into standby mode)? Are/were people using screen savers just to avoid the few seconds the monitor needs to turn back on or is there another reason?

                                      1. 2

                                        Certain screensavers can help with burn in on OLED displays, turning the display off does not help. I don’t know the actual science behind it, I just know it worked on an OLED display I had that had burn in. ;)

                                        1. 2

                                          Note that a screensaver is unlikely to have that property unless it was designed to. Those screen-healing screensavers usually use colored geometric patterns.

                                          I remember one of the patterns in such a screensaver was a series of black and white vertical stripes that slowly scrolled sideways. I once had the idea of making a free clone of that screensaver, so I replicated that pattern in Quartz Composer, Apple’s visual programming tool for generating graphics. I never remade any of the other patterns though.

                                  1. 4

                                    Failing more aggressively on these errors means not allowing the application to continue running in a corrupted state — reducing the distance between where you trip (the real problem occurs) and where you hit the ground (when React blows up because its internal bookkeeping is corrupt). This makes certain errors in React components easier to understand and fix.

                                    This metaphor for explaining the difference between an incorrect action that causes an error and the arrival of the error itself is wonderful and I’m totes stealing it in future.

                                    1. 1

                                      Thanks! I myself stole it from a mentor of mine who used it in the context of C++, where you can imagine lots of bugs present themselves this way.

                                    1. 5

                                      this is cool! for those interested, this article is another interesting exploration of the tradeoffs of a super simple react (not redux) clone: http://uniphil.github.io/virtual-dom/

                                      previous discussion: https://lobste.rs/s/pzjlrd/virtual_dom_is_not_feature

                                      1. 3

                                        Thanks for the links; they’re very helpful! The limitation described in the article you linked to is the same that I ran into: just replacing the whole DOM tree on each update, as fast or slow as innerHTML may make it, makes it impossible to create viable interfaces which update every time the user types a character into the UI. It also hurts accessibility.

                                        For a moment I was tempted to try and somehow mark DOM elements which should update on key press events etc. I would then need to also prevent re-renders… which essentially puts us back to square one: two-way bindings. In the end I decided to make this a known limitation of innerself. It’s probably fine to say that you can’t create every imaginable interface in it. I’m less happy about how inaccessible it ends up being.

                                        It makes me wish for a Virtual DOM diffing done natively by the browser.

                                      1. 2

                                        I’ve been using it for the last month. It’s great. I’d be so much slower without it and I’m still learning Rust.

                                        1. 3

                                          Is there any assistance with borrowing/ownership issues? Seems like that’s a major thing in Rust where IDEs could help.

                                          1. 2

                                            Not directly, but at least it has refactoring support for elding/unelding lifetimes quickly, which is usually the first thing you do when debugging.

                                            1. 2

                                              I have limited familiarity with lifetimes in rust - what do you mean by elding here?

                                              1. 4

                                                “Eliding”, that is, hiding (or showing) simple, easily-inferred lifetimes that the compiler does not require to be explicitly annotated.

                                        1. 6
                                          1. 1

                                            thoughts? intrigued by the list of authors!

                                          1. 1

                                            Disclaimer being that I work for sentry, but for the simple servers and scripts that I run on my VPS, i always integrate sentry on them. I find it convenient as a first resort for “why did my twitter bot break” type questions.

                                            None of the applications that I run right now are important or complex enough for me to worry about configuring system-level tools.

                                            1. 13

                                              I wrote a script that makes my twitter avatar spin as an hour clock. I’m going to open source it this week.

                                              It’s completely pointless and I’m absolutely delighted by it :D

                                              1. 2

                                                I think you managed to upload a broken image (which to me is even cooler!)

                                                https://pbs.twimg.com/profile_images/866716868836564994/4blEmhkL_400x400.png

                                                (edit: it now appears to be working as you intended)

                                              1. 2

                                                I’ve used Hershey fonts recently as data to generate vectors for a pen plotter. Still useful!

                                                example example

                                                1. 1

                                                  enjoyed this quick take! the pmap solution seemed like the quickest win to me, but I would be interested to see a solution that automated the splitting as well.

                                                  1. 1

                                                    Does anyone know whether something in this style exists for the little schemer?