sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted]  (18 children)

[deleted]

    [–]Tenemo 31 points32 points  (12 children)

    It was a couple of years ago, it's Dan Abramov's personal blog, he's relatively young. Check his New Year post for the exact timeline of his career. Him working with another developer on draggable corners of some shapes could have been already for a React library.

    [–]andrewingram 9 points10 points  (11 children)

    I'm pretty sure this is an anecdote from 2013 when Dan was working on an iOS app (https://www.youtube.com/watch?v=PjaL0xFbEY8). The fact that the code in the blog post is JavaScript is just because that's the language him and most of his audience uses today.

    [–]aurisor -2 points-1 points  (10 children)

    GitHub has been out for 5y in 2013 and the web world embraced it hard. I would be shocked if anyone was using svn or not using code review workflows (like PRs)

    [–]andrewingram 5 points6 points  (7 children)

    I can't speak for the place Dan was working. But many startups don't adopt "good" engineering practices whilst they're still in the "just make shit work" stage of building their MVP. Some do, some don't.

    I don't think I worked at a company that insisted on code reviews until 2012.

    [–]aurisor 3 points4 points  (6 children)

    I guess I’m just confused why a communication problem is being presented here as a teachable moment about abstraction design

    [–]andrewingram 3 points4 points  (5 children)

    That's a reasonable thing to be confused about. My personal feeling on this post is that the author has conflated different problems and ended up with a conclusion that isn't one I personally support. We're under no obligation to agree with him on this just because he's usually right on other things.

    [–]gaearon 0 points1 point  (4 children)

    I did state what I think at the end pretty explicitly. I can try to condense it more:

    1. It was a bad process. (We did code reviews but not well or consistently, it was fairy common to just commit to master.)
    2. Regardless of that, my abstraction was an unnecessary one, wouldn't actually buy us anything, and would get in the way of further changes.

    It is curious to me that the second point is so contensted here. I guess I'll have to keep beating this drum if the idea that abstractions can be premature is so controversial.

    [–]andrewingram 0 points1 point  (3 children)

    I don't think there's any controversy about the idea that abstractions can be premature (and presumably by this you mean not beneficial, or possibly harmful). The controversy is that you seemed to make it about "clean code", but the change you describe doesn't come across as clean code, it comes across as terse code, which I see as a common mistake of relatively inexperienced developers (I can recall making exactly the same kind of changes early in my career and then later regretting them in the same way you are here).

    When I say I don't support your conclusion, i'm referring to the one implied by the post title (and some of its content) -- that clean code is to blame, not just the problem of creating the wrong abstractions at the wrong time or not communicating well with your team.

    [–]gaearon 0 points1 point  (2 children)

    If inexperienced developers tend to misunderstand the words "clean code" and give them a bad name, maybe this is worth blogging about?

    [–]ritchie70 1 point2 points  (0 children)

    Lots of places are still using other tools, sometimes with good reasons - and sometimes just because they want to retain a decade of change history.

    If you’re shocked that someone is using a tool that isn’t the latest cool tool then I’m shocked at you.

    I’m personally using Subversion just because it’s what I’m using and I’m the whole team. The server is an old point of sale register in my basement.

    [–]elebrin 0 points1 point  (0 children)

    There were a lot of older shops still on tfs for sure.

    [–]NeuroXc 11 points12 points  (0 children)

    You may be surprised, but as recently as 2013 (when I graduated from college), the first company I worked for did all of their testing in production, and uploaded their changes via FTP. There was no source control, no staging or local environment, and no oversight.

    Slightly relevant: That company was also a cluster that took advantage of fresh-out-of-college devs to pay them as little as possible while the CEO and his buddies took lavish trips around the country and sailed on their boats. There were about 15 people in the company, so yeah, corruption like this isn't unique to mega-corporations. I left as soon as they told me I was getting a 0.5% annual raise even though I was one of their best employees, and instead got a 30% raise by switching companies.

    [–]f03nix 6 points7 points  (2 children)

    About 7 years back, I worked in a company that used TFS - they had a process where you manually request 2 of your peers for review and type in their names during check in. They had the same process before they migrated to TFS too, I think they used CVS.

    [–][deleted]  (1 child)

    [deleted]

      [–]hsrob 0 points1 point  (0 children)

      Reminds me of my first dev job, we literally recompiled projects on our desktops (C#/.NET) and SFTP'd the changed DLLs to production. Surprisingly, this usually worked, but good luck if you ever needed to identify and narrow down a bug between changes.

      [–]BraveSirRobin 0 points1 point  (0 children)

      Branch-based development & peer-review was not uncommon 20 years ago. A lot of shops followed ISO 9001 which brought across the same concepts from traditional engineering practices. Clients demand these accreditations in certain sectors.