Threads for revx

  1. 1

    This post got me thinking, so I dug through some old archives and found this page I put online in Jan 2001, and just put it back online: https://erty.me/oldest/

    I hasn’t been online continuously (and was originally hosted on a different domain), but the file attributes still have the creation date as Jan 2001.

    I also found and reuploaded my first multi-page website, a school project about riparian areas, that I put online in May 2002: https://erty.me/riparianareas/

    I built it in Microsoft Frontpage, and some of the generated javascript was so old that the site was broken and nothing showed up - document.body.sourceIndex doesn’t exist anymore! So, I had to do some little polyfills to bring this up to the 2020s :)

      1. 5

        That’s termination free iteration, not recursion.

        Recursion must have a base case

        1. 2

          The base case is “are you bored yet?”

          1. 1

            Was about to say this but you beat me to it!

          2. 3

            It took me far too long to get this…

            Relatedly, I also like this post about recursion.

            1. 2

              I’m on to you (ಠ_ಠ)

          1. 2

            Cool! Seems like a big upgrade over the first version. Love the colors.

            Unfortunately, I wasn’t able to get past the third level or so, because the confetti rain wouldn’t stop.

            1. 1

              Thank you for running it, revx! I had a blast attending, even bought my first MIDI controller (IIRC) after one talk.

              1. 1

                Amazing, thank you for attending!

              1. 5

                Could you help me to understand this statement?

                Experiance shows that names are […] not guaranteed […] even to exist for each person you (or your software) will encounter.

                There’s a footnote pointing to “Falsehoods Programmers Believe About Names”, which includes “people have names” as the final falsehood in its list. This stuck out to me when I first read that article, too, but I confess I never looked into it further.

                Is this supposed to be tongue-in-cheek, or is this a genuine assertion that some people do not have names? What are the cultures or contexts in which this occurs? If a piece of software addresses its users (“Welcome, Xavier”) or lists them by name, what might be considered correct behavior in this case?

                1. 10

                  Yes, it’s true that in some cultures people don’t have names for some portions of their lives. Most commonly, I believe, it’s as infants. I suggest the book The Spirit Catches You And You Fall Down for a great overview of what happens when cultural expectations like this clash in a healthcare context.

                  1. 3

                    Anecdotally, my wife and I did this - our child was unnamed for about 24 hours.

                    1. 1

                      Ah, of course. Patrick McKenzie explicitly mentioned that possibility earlier in his list but I failed to make the connection. Thanks!

                    2. 6

                      From the brilliant Data and Reality:

                      We also have some issues regarding the beginning and ending of a person. It makes sense in the context of some medical records to treat an unborn fetus as an unborn person; observations during pregnancy become a part of that person’s medical history. A recent court case considered the question of whether an unborn fetus was eligible for welfare benefits, which would have made the fetus representable in the welfare database.

                      Also, in (Ashkenazic?) Jewish tradition, boys aren’t named until they’re eight days old.

                      1. 1
                        1. 2

                          Yeah, though I’m quoting from the second edition. The third edition was edited by someone else after Bill Kent died, who crammed in his own contradictory “data modeling” consulting.

                      2. 5

                        How do you handle someone who declines to give a name and insists on anonymity? How do you handle someone who’s incapable of telling you a name to use for them?

                        Legal systems sometimes have conventional placeholders to use for these situations, but it would be a mistake to assert that the placeholder is the person’s name.

                        1. 2

                          Parents don’t always have a final name lined up for a child by the time they’re born or they lose track of some bureaucratic step amid all the chaos of having a new child, thus temporarily leaving the child without a legal name. Or children abandoned at birth without a hospital record.

                        1. 7

                          I’d be interested to see what the compiler came up with, to compare it to your hand-written code?

                          1. 1

                            You can? :) I didn’t include a comparison because the post would’ve gotten huge but I did mention I peeked into it.

                          1. 23

                            I would maybe use Go/Rust

                            “Go/Rust” is a great shortcut for “I don’t know anything about programming languages”. ;)

                            1. 13

                              I think your average “dark matter” type of programmer isn’t going to have much exposure to these. Of course, I think Go is likely to become one of those dark matter developer languages like Java or VB became.

                              1. 4

                                I thought that a) Go is already a dark matter language b) people who think Rust is like Go already know Go and fell victim to the Blub phenomenon. I may be wrong on both counts of course,

                                1. 9

                                  Depends on the timeframe. For your typical Bay Area shop, your typical “SRE DevOps Peon” will likely use Go. Outside of the HN bubble, most companies doing line-of-business type stuff that aren’t hopelessly outdated are usually doing it still in Java/C#/PHP, maybe JS.

                                2. 2

                                  It could be. I tried to do a project in Go. I couldn’t easily express ideas due to how basic its primitives are. That Rob Pike quote became real for me. I just tossed that entire prototype, kept using Python, and started looking at more expressive languages.

                                  On the plus side, I can see how its simplicity makes onboarding easier, probably easier to maintain random codebases than C++ or Java/.Net, and dramatically improves ability to make the tooling. It just didn’t fit me. I could see me using a more expressive language that outputs something like Go in human-readable form to keep those benefits, though. I just gotta keep my personal productivity up since it’s scarce to begin with (outside work).

                                3. 12

                                  I don’t think this is fair.

                                  I have to use both Rust and Go at work - compared to other mainstream languages these happen to be two of three that give you automatic memory management and memory safety without outsized and unpredictable latency penalties for typical software.

                                  I understand where you’re coming from, because the mechanisms they for this are quite different - Rust accomplishes this via stack allocation by default via the borrow checker and RAII and Go accomplishes this via the combination of automatic stack allocation via escape analysis and the core team’s focus on the impact of garbage collection latency - but that doesn’t mean that they aren’t reasonable to group together among other mainstream programming languages in 2020.

                                  1. 5

                                    I feel like this is the point of the article, though! OP hasn’t had time to actually put in research about it and won’t have time, unless it becomes a direct part of their job.

                                    1. 4

                                      I wouldn’t go that far; while this person is self-admittedly a very average programmer, and while there are some reasons to view Rust and Go as languages that are best suited for two different categories of work, they do share some important commonalities that the author is rightly picking up on. Both of them had the design goals of being immediately, practically useful to mainstream software engineers (rather than being research languages exploring esoteric PL theory features). They were consolidations of a few decades of lessons learned from the flaws of other mainstream programming languages, rather than trying to do anything radically new. They both spent a lot of effort on building practical tooling around the compiler. And they were both developed at roughly the same time. There are quite a few areas of programming where either Go or Rust would be a reasonable choice.

                                      1. 2

                                        Disagree, I see quite a few problems and requirements where I’d use one of the two over, say, C++ and with the same reasons I wouldn’t use Python or PHP.

                                        You’re just as much overgeneralizing as the author did.

                                        1. 2

                                          In one of the rule on C / C++, Rust could be an alternative there. I think comparing Rust to C / C++ would be better than Go.

                                          1. 1

                                            Ok wait but the rest of the sentence qualifies:

                                            I would maybe use Go/Rust if I was building a fresh web service where latency, and performance were more important than community/library support.

                                            Maybe a more precise spelling would have been “Go or Rust” instead of “Go/Rust”, but I think the meaning was clear given the whole sentence.

                                          1. 14

                                            I think the other reason is that, if you get the full post on the RSS feed, the site doesn’t get the chance to show you ads.

                                            1. 2

                                              Very cool! One small nit: I would love to be able to see the date I’m at while I’m sliding the slider and looking at the symbols.

                                              1. 3

                                                Added. That is better, thanks!

                                              1. 7

                                                I’ve been doing advent of code in Haskell. I’m way behind (it’s over and I’m stuck on day 14). But one of the things that finally got me going with it was to give up on writing fancy Haskell and just write the program to solve the problem. I’m sure I’m doing all sorts of things wrong - my Haskell feels very Pythonic. But the answers are correct and I’m learning things along the way that I never would have picked up if I hadn’t written it the “junior” way first.

                                                For example, I just implemented my first “instance” of a typeclass. I don’t quite understand everything behind the code, but I’m starting to unfold the ideas in my head by working with them. In fact, I think it’s important that I’m learning the “feel” of the code before the being able to name things. If you asked me to point out a lens in my code, for example, I would have no idea - but I’m sure I’m using several of them. Eventually the idea will click.

                                                I was inspired to do this by a blog post I read recently where the author promoted the idea of teaching a thing by soliciting predictions about how it will work and how it will change, instead of teaching the “grammar” first. Kids learn their first language this way - we don’t know what future perfect tense is, but we know how to use it.

                                                I read just enough of Learn You a Haskell to start programming AoC day 1, and I refer back to it when I need to pick up a new tool to keep moving. It’s been fun!

                                                1. 2

                                                  I did some AoC days in Hakell, or as I like to say, baby haskell. Because I’m pretty new at the language, so I can’t use any of the advanced things. A certain someone looked at my code and asked me why my haskell looked like fortran though. https://github.com/cosarara/aoc2019/blob/master/day13/day13.hs

                                                  1. 1

                                                    Me too! I’ve only gotten through Day 7, because two toddlers and new job, but I enjoy fiddling around on smallish problems in Haskell.

                                                    1. 1

                                                      Hah, I hope you’re proud of that comment!

                                                      I do agree that the code is a bit hard to read, mostly due to all the integer constants (which I’m sure are because of the problem statement). It could be a fun exercise to gradually improve this (though the code is fine as is!). My first suggestion would be to move from some of those integers to dedicated types where it makes sense (e.g. enumerate the operations in a type Op, and write a function parseOp :: Int -> Op that will error on parsing instead of interpretation).

                                                  1. 4

                                                    When I was in college, I almost quit my computer science major several times. Once, I went down to my advisor’s office and told him that I wanted to quit the major. He handed me the forms and I went back to my dorm and filled them out. But for some reason I never turned them in. Instead I went back to studying and eventually graduated with the major.

                                                    I think the most important thing was that I surrounded myself with other students. My partner at the time (now my wife) was really the one who told me to keep working at it. She studied much, much harder than I did and inspired me to keep at it. I’m so glad I did. Words of encouragement (or conversely, discouragement) are incredibly poweful.

                                                    1. 3

                                                      My personal favorite is http://thecodelesscode.com/case/41 – I quote it at anyone who tries to comment out chunks of code in production.

                                                      1. 2

                                                        Managed by Q is hiring engineers and product managers. We’re building software to run, create, and manage office space. We also employ thousands of maintenance and cleaning operators who make a living wage + benefits, since we believe in providing good jobs for people.

                                                        If you’re interested in building a company that believes in sustainable employment and helps small businesses while building interesting tech, get in touch! We have an engineering team of about 20 people in SoHo, NYC. I’m an engineer at the company – email me (eseidohl at our domain) if you have questions or want to talk about MbQ!

                                                        1. 1

                                                          Do these ghost characters have a sound that goes with them? Or are they completely meaningless?

                                                          1. 2

                                                            It looks like 彁 might be pronounced sei ka, but I’m not sure where that pronunciation comes from. https://en.wiktionary.org/wiki/%E5%BD%81

                                                          1. 5

                                                            I’m trying to convince my workplace to get rid of whiteboarding interviews, does anyone know if there are resources for ideas of alternatives? Anyone have a creative non-whiteboarding interview they’d like to share?

                                                            1. 7

                                                              The best that I’ve found is to just ask them to explain some tech that’s listed on their resume. You’ll really quickly be able to tell if its something they understand or not.

                                                              My team does basic networking related stuff and my first question for anyone that lists experience with network protocols is to ask them to explain the difference between TCP and UDP. A surprising number of people really flounder on that despite listing 5+ years of implementing network protocols.

                                                              1. 6

                                                                This is what I’ve done too. Every developer I’ve ever interviewed, we kept the conversation to 30min-1hr and very conversational. A few questions about, say, Angular if it was listed on their resume, but not questions without any context. It would usually be like- “so what projects are you working on right now? Oh, interesting, how are you solving state management?” etc. Then I could relate that to a project we currently had at work so they could get a sense of what the work would be like. The rapid-fire technical questions I’ve find are quite off-putting to candidates (and off-putting to me when I’ve been asked them like that).

                                                                As a side note, any company that interviews me in this conversational style (a conversation like a real human being) automatically gets pushed to the top of my list.

                                                                1. 4

                                                                  Seconded. Soft interviewing can go a long way. “You put Ada and Assembler on your CV? Oh, you just read about Ada once and you can’t remember which architecture you wrote your assembly for?”

                                                                  1. 3

                                                                    I often flunk questions like that on things I know. This is because a question like that comes without context. If such a problem comes up when I’m building something, I have the context and then I remember.

                                                                    1. 6

                                                                      I don’t think any networking specialist would not know the difference between TCP and UDP, though. That sounds like a pretty clear case of someone embellishing their CV.

                                                                      1. 4

                                                                        So if you can’t whiteboard and you can’t talk about your experience, what options are left? Crystal ball?

                                                                        1. 3

                                                                          I like work examples, open ended coding challenges: Here’s a problem, work on it when you like, how you like, come back in a week and lets discuss the solution. We’ve crafted the problem to match our domain of work.

                                                                          In an interview I also look out for signs of hostility on the part of the interviewer, suggesting that may not be a good place for me to work.

                                                                    2. 5

                                                                      A sample of actual work expected of the prospective employee is fair. There are pros and cons to whether it should be given ahead of time or only shown there, but I lean towards giving it out in advance of the interview and having the candidate talk it through.

                                                                      Note that this can be a hard sell, as it requires humility on the part of the individual and the institution. If your organization supports an e-commerce platform, you probably don’t get to quiz people on quicksort’s worst-case algorithmic complexity.

                                                                      1. 7

                                                                        I certainly don’t have code just sitting around I could call a sample of actual work. The software I write for myself isn’t written in the way I’d write software for someone else. I write software for myself in Haskell using twenty type system extensions or in Python using a single generator comprehension. It’s for fun. The code I’ve written for work is the intellectual and physical copy of my previous employers, and I couldn’t present a sample even if I had access to it, which I don’t.

                                                                        1. 5

                                                                          Yup, the code I write for myself is either 1) something quick and ugly just to solve a problem 2) me learning a new language or API. The latter is usually a bunch of basic exercises. Neither really show my skills in a meaningful way. Maybe I shouldn’t just throw things on GitHub for the hell of it.

                                                                          1. 4

                                                                            Oh, I think you misinterpreted me. I want the employer to give the employee some sample work to do ahead of time, and then talk to it in person.

                                                                            As you said, unfortunately, the portfolio approach is more difficult for many people.

                                                                            1. 1

                                                                              I write software for myself in Haskell using twenty type system extensions or in Python using a single generator comprehension. It’s for fun.

                                                                              Perhaps in the future we will see people taking on side projects specifically in order to get the attention of prospective employers.

                                                                          2. 3

                                                                            I recently went through a week of interviewing as the conclusion of the Triplebyte process, and I ended up enjoying 3 of the 4 interviews. There were going to be 5, but there was a scheduling issue on the company’s part. The one I didn’t enjoy involved white board coding. I’ll tell you about the other three.

                                                                            To put all of this into perspective, I’m a junior engineer with no experience outside of internships, which I imagine puts me into the “relatively easy to interview” bucket, but maybe that’s just my perception.

                                                                            The first one actually involved no coding whatsoever, which surprised me going in. Of the three technical interviews, two were systems design questions. Structured well, I enjoy these types of questions. Start with the high level description of what’s to be accomplished, come up with the initial design as if there was no load or tricky features to worry about, then add stresses to the problem. Higher volume. New features. New requirements. Dive into the parts that you understand well, talk about how you’d find the right answer for areas you don’t understand as deeply. The other question was a coding design question, centered around data structures and algorithms you’d use to implement a complex, non-distributed application.

                                                                            The other two companies each had a design question as well, but each also included two coding questions. One company had a laptop prepared for me to use to code up a solution to the problem, and the other had me bring my own computer to solve the questions. In each case, the problem was solvable in an hour, including tests, but getting it to the point of being fully production ready wasn’t feasible, so there was room to stretch.

                                                                            By the time I got to the fourth company and actually had to write code with a marker on a whiteboard I was shocked at how uncomfortable it felt in comparison. One of my interviews was pretty hostile, which didn’t help at all, but still, there are many, far better alternatives.

                                                                            1. 1

                                                                              I’m a little surprised that they asked you systems design questions, since I’ve been generally advised not to do that to people with little experience. But it sounds like you enjoyed those?

                                                                            2. 1

                                                                              There are extensive resources to help with the evangelism side of things.

                                                                            1. 30

                                                                              Other important political aspect of Material Design (and some other UI/web styles that are popular now) is “minimalism”. Your UI should have few buttons. User should have no choices. User should be consumer of content, not a producer. Having play and pause buttons is enough. User should have few choices how and what to consume — recommender system (“algorithmic timeline”, “AI”) should tell them what to consume. This rhetoric is repeated over and over in web and mobile dev blogs.

                                                                              Imagine graphics editor or DAW with “material design”. It’s just nearly impossible. It’s suitable only for scroll-feed consumption and “personal information sharing” applications.

                                                                              Also, it’s “mobile-first”, because Google controls mobile (80% market share or something like that). Some pages on Google itself (i.e. account settings) look on desktop like I’m viewing it on giant handset.

                                                                              P.S. compared with “hipster” modernist things of ~2010, which often were nice and “warm”, Material Design looks really creepy for me even when considering only visual appearance.

                                                                              1. 10

                                                                                A potentially interesting challenge: What does a design language for maker-first applications look like?

                                                                                1. 17

                                                                                  Not sure if such design languages exist, but from what I’ve seen, I have feeling that every “industry” has its own conventions and guidelines, and everything is very inconsistent.

                                                                                  • Word processors: lots of toolbar buttons (still lots of them now, but in “ribbons” which are just tabbed widgets). Use of ancient features like scroll lock key. Other types of apps usually have actions in menus or in searchable “run” dialogs, not toolbar button for each feature.
                                                                                  • Graphics editors: narrow toolbars with very small buttons (popularized by both Adobe and Macromedia, I think). Various non-modal dialogs have widgets of nonstandard small size. Dark themes.
                                                                                  • DAWs: lots of insane skeuomorphism! Everything should look like real synths and effects, with lots of knobs and skinning. Dark themes. Nonstandard widgets everywhere. Single program may have lots of multiple different styles of widgets (i.e. Reason, Fruity Loops).
                                                                                  • 3D: complicated window splits, use of all 3 mouse buttons, also dark themes. Nonstandard widgets, again. UI have heritage from Silicon Graphics workstations and maybe Amiga.

                                                                                  I thought UI guidelines for desktop systems (as opposed to cellphone systems) have lots of recommendations for such data editing programs, but seems that no, they mostly describe how to place standard widgets in dialogs. MacOS guidelines are based on programs that are included with MacOS, which are mostly for regular consumers or “casual office” use. Windows and Gnome guidelines even try to combine desktop and mobile into one thing.

                                                                                  Most “editing” programs ignore these guidelines and have non-native look and feel (often the same look-and-feel on different OSes).

                                                                                  1. 3

                                                                                    3D: complicated window splits, use of all 3 mouse buttons, also dark themes. Nonstandard widgets, again. UI have heritage from Silicon Graphics workstations and maybe Amiga.

                                                                                    Try Lisp machines. 3D was a strong market for Symbolics.

                                                                                  2. 9

                                                                                    I’d suggest–from time spent dealing with CAD, programming, and design tools–that the biggest thing is having common options right there, and not having overly spiffy UI. Ugly Java swing and MFC apps have shipped more content than pretty interfaces with notions of UX (notable exceptions tend to be music tools and DAW stuff, for reasons incomprehensible to me). A serious tool-user will learn their tooling and extend it if necessary if the tool is powerful enough.

                                                                                    1. 0

                                                                                      (notable exceptions tend to be music tools and DAW stuff, for reasons incomprehensible to me)

                                                                                      Because artists demand an artsy-looking interface!

                                                                                    2. 6

                                                                                      We had a great post about two months back on pie menus. After that, my mind goes to how the Android app Podcast Addict does it: everything is configurable. You can change everything from the buttons it shows to the tabs it has to what happens when you double-click your headset mic. All the good maker applications I’ve used give me as much customization as possible.

                                                                                      1. 2

                                                                                        It’s identical to the material design guidelines but with a section on hotkeys, scripts, and macros.

                                                                                      2. 5

                                                                                        P.S. compared with “hipster” modernist things of ~2010

                                                                                        What do you mean by this

                                                                                        1. 4

                                                                                          Stuff like Bootstrap mentioned there, early Instagram, Github. Look-and-feels commonly associated with Silicon Valley startups (even today).

                                                                                          These things usually have the same intentions and sins mentioned in this article, but at least look not as cold-dead as Material Design.

                                                                                          1. 3

                                                                                            Isn’t this like… today? My understanding was: web apps got the material design feel, while landing pages and blogs got bootstrappy.

                                                                                            I may be totally misinterpreting what went on though

                                                                                          2. 3

                                                                                            Bootstrap lookalikes?

                                                                                        1. 3

                                                                                          This seems off-topic to me. A company is moving, what’s technical about that?

                                                                                          1. 4

                                                                                            I think there’s some selection bias – there’s lots of recursers on lobste.rs, so stuff about recurse is more likely to hit the front page.

                                                                                            1. 1

                                                                                              You’re correct. If it had more information about the logistics of, say, outfitting their new network infra or whatever, that’d be one thing–as it is, it’s a press release. Good catch.

                                                                                              1. 1

                                                                                                Given it’s currently hidden by five users, you’re probably on to something. Based solely on my completely 100% scientific half-paying attention observation powers, five is high.

                                                                                                1. 1

                                                                                                  General rule Ive observed is on/off topic isn’t worth mentioning if it has a lot of upvotes. Many readers already voted for it yo be here at that point. On top of that, several high-voted submissions happened while the people were at RC. That boosts popularity further.

                                                                                                1. 4

                                                                                                  I’m getting an HTTPS error

                                                                                                  1. 8

                                                                                                    Welcome to tedu - do you trust him?

                                                                                                  1. 1

                                                                                                    This looks really cool, the quality of the talks looks amazing. I kinda want to submit but I’m afraid I won’t be able to pull together something awesome enough.

                                                                                                    1. 1

                                                                                                      I encourage you to submit something anyway! Some of my favorite talks have been about something that seemed trivial to the speaker, but that I’d never even heard of before :)

                                                                                                    1. 32

                                                                                                      Oh boy, I have a lot of feelings about this. Good on the author for bringing it up.

                                                                                                      Junior developers (having been one) are amazing to have around and, if handled properly, are a major force multiplier.

                                                                                                      Personally observed benefits of junior devs:

                                                                                                      • They are hungry. They are looking to get that paycheck, no matter how small it is compared to a senior developer, and since they’re often hourly they’ll actively look for additional work to do if managed properly to pad out beer money or rent or childcare or family care or whatever. Senior devs begin playing a game (if they’re smart) of “I am salaried…how can I exert minimum effort for maximum possible revenue?” Senior devs also know themselves better, and so they can often say “Yeah, $X is enough, I don’t see the personal upside in taking on more work even with a pecuniary benefit”.
                                                                                                      • They don’t know what is hard and what isn’t. They are juniors, and so they attack tasks (architectural and scutwork) with near equal optimism. You can give them something that’s impossible and they’ll come back with solutions that actually are good-enough fudges for business purposes.
                                                                                                      • They want to learn. The only way to become a senior developer is by learning things, and a lot of junior devs have a chip on their shoulder (acknowledged or not) about not knowing enough–so, they’ll go do new things and learn about them and try to show off that learning. Senior devs often go with tried-and-true knowledge because they know how to execute most quickly with it; a junior dev can help uncover better solutions that would be ignored otherwise.
                                                                                                      • They might know things you don’t. Hell, I learned React in from an excellent junior dev.
                                                                                                      • They’ll stick around longer. Similar to being hungry, the friction for a junior dev to switch companies is higher (they underestimate their own knowledge and value, remember?) than for a senior dev. So, if you display even marginal competence and compassion towards them, they probably won’t jump ship. Also, their pay scale starts so much lower so that you can keep giving real raises without worrying about breaking the bank.

                                                                                                      However, there are severe pathologies to junior devs:

                                                                                                      • They suffer extra from morale-stressing situations (modulo life experience). A junior dev can get stuck in a project or stuck with a bad situation and really just ground down by it, where in the same place a senior might go “well, this sucks, but we can see it through”. They haven’t had a lot of history of failed and successful projects, so they can take things too hard.
                                                                                                      • They love learning new things, and want to try them out all the time. Until trained properly, junior devs have very little conservatism in their engineering. They’ll switch from Backbone to Angular to React because they’re learning new and exciting things–even if the original domain just needed a static server-side page.
                                                                                                      • They are really bad at software estimates. Like, even moreso than normal, because they lack the breadth of experience to know what paths in a project are probably most filled with spiders and which ones are tedious but quick.
                                                                                                      • They are bad at managing others. Juniors are just barely getting their own career and projects in order, and usually lack the technical, political, and engineering proficiency to organize and communicate effectively with others in a leadership role. This does not mean they shouldn’t (with careful and direct supervision) be forced into it–after all, that’s how they learn!
                                                                                                      • Modulo life experience, they focus on tech more than customers. Due to their desire for knowledge and improvement, they often miss the essential chatting with customers/users of a software project that can pull out hidden requirements or even allow for shipping partially complete work.
                                                                                                      • They can make a huge mess. Given credentials to production system, or given large foundational architecture work, juniors can do bizarrely well-intentioned things that result in total chaos. Seniors can (and do!) have the same problems, but they’re usually more likely to ask for help or exercise caution.
                                                                                                      • Modulo life experience, they don’t understand themselves. Juniors have a hard time spotting when they’re getting overloaded or burned out, and they have a hard time figuring out why they feel a certain way about technical and interpersonal conflicts. This results in communication problems, chaos, and general bad vibes until addressed.
                                                                                                      • They will dutifully reproduce the dev practices around them. So, if all of the example code for solving something does weird shit, juniors will dutifully continue doing weird shit. If the build process is crackheaded and error-prone, the juniors will dutifully keep running it and running into problems and, as noted above, probably continue creating problems. And they’ll teach other more-junior devs to do the same!

                                                                                                      I’ve got thoughts on the care and feeding of junior devs, but this post is already rather long.

                                                                                                      1. 4

                                                                                                        Thanks for sharing this, you’ve crystallized a lot of my own thoughts on junior devs excellently. I taught at a bootcamp for a while, and my favorite thing about new dev you summed up as, “They don’t know what is hard and what isn’t.” It was so cool to see these fresh students attack problems that I would have immediately dismissed simply because they didn’t know how hard it was. I think this is an excellent lesson for senior devs as well, a kind of “beginner’s mind” that’s hard to obtain.

                                                                                                        I think any project is like this: if you knew how tough it would be at the end, you probably wouldn’t have started it. Our ability to over- and under- estimate can sometimes be a huge boon.

                                                                                                        1. 4

                                                                                                          If you get the urge to write about the care and feeding of junior devs, I would be interested in reading it.

                                                                                                          1. 2

                                                                                                            It’s not totally independent of the items you’ve listed, but one thing I’ve noticed about juniors is that they also don’t stop to think whether the things they build upon are designed to be taken to scale. So with juniors around, it can be dangerous to say “OK, let’s embrace the fact that we have 5-10 of these things currently, so we’ll do something quick that relies on this fact, and we’ll switch to something more sensible when we need to scale in this direction.”. The moment you look away, you’ll find that a junior has written a script to auto-generate thousands of those things and built an entire structure around it without questioning whether the rest of the system was ready for it (however obvious that might seem to you).

                                                                                                            I think the broader point here is that juniors are much more susceptible to tunnel vision, where they only focus on what they’re trying to solve at a given moment without considering the big picture.