Davertron

I guess I'll be the exception here. I'm in a psudeo-open workspace right now which is pretty much what you're talking about except that we're not in a room, it's what the company calls a "pod" with high walls and a single doorway. I would say 90% of all distractions etc. come from inside the pod. Moving us into our own room would make no difference. It does get pretty loud sometimes in the building, but it's mostly white noise and easy (at least for me) to ignore. The only way to work mostly without distractions here is to wear headphones, which generally signals to others that they should leave you alone, but even then people will still just wander over and bother you because you're right there. For some people the idea of chatting someone who's sitting 5 feet away from them is super weird.

The most productive times I have, hands-down, are when I work from home.

I learned to play hockey about 5 years ago. Part of that was going to stick and puck sessions during the week, where I could basically do whatever I wanted; work on skating, stick handling, etc. Sometimes there would be literally no one else at the rink, and during those times it was super fun being a noob. I had a ton of stuff I could work on, and I would see progress from week-to-week. I started playing on a real team not long after starting to learn, and the games were the opposite. I just felt super embarrassed the whole time.

OK, but are there actually more people who believe in this now, or are you just more aware of it?

I agree that it's not uncommon to hear things on the development team that basically amount to "if it weren't for our users our application would be so much simpler" :)

We have spent a significant chunk of time working directly with our users during this migration. This is an internal tool, so we can literally walk over and talk to our user base if we have questions or want suggestions on things. We have done surveys, we track using analytics, we have a user council that we meet with regularly to run ideas by and get feedback on our work and they come to our sprint reviews (well, 3 of them do...) to see what new work we've done etc. etc.

This doesn't change the fact that you can't make everyone happy. One user will tell us that they hate the way a certain page is designed and that they won't use it because it doesn't fit their workflow. Another user will tell us the exact opposite. So we have to take the feedback and make a judgement call, using the data we have available, to try and make the best decision. One great thing about having analytics is it helps you identify squeaky wheels. We had some people on our user council that would basically complain about every single thing we did. If you just listened to them, you would have been tempted to just give up. When we looked at the data, we realized 90% of our user base was getting A LOT of work done, and we weren't hearing anything from them. Obviously it was possible they also hated the app and just didn't want to tell us, but after reaching out it became clear that they were perfectly happy with the way it worked and were just getting shit done. In my experience, the temptation is just to listen to the people you're getting feedback from and assume that they're a representative sample. DON'T. Do the work (or put the systems in place) to help you vet the feedback you're getting.

Another thing that makes this very difficult is one of the things you're touching on; trying to develop a tool for a domain that you don't have intimate knowledge of makes it pretty difficult to know which way to go when you are getting conflicting information. None of the developers is an expert user in the domain (or even a beginner for that matter...) and so we often end up having to look at things from a higher level (i.e. what other applications have we used that function this way? How do they solve this problem? etc.). I think this mostly works, but there are bound to be some misses here or there.

I think this plays a role in the difficulty of the migration, because yes, the interface has changed quite a bit. In general, we tried to hew as close to the old paradigms as made sense. We never changed anything just because we didn't like it; we tried to make sure that the transition would be easy and the users didn't have to drastically change their mental models. But of course, there are always going to be differences in look/feel/capability between native applications and the web. I will say the web has come a long way since I started as a web developer 15 years ago and it feels like closing this gap is more a priority these days.

But there were parts of the application that were poorly designed (our users told us so...) and so, even though they were the primary ones driving change, there's always pain when changing to a new way of doing things.

My team has been working on a big-bang rewrite for about 5 years now. It started out as the "strangle" approach. Early on, everyone was on board with killing the old thing. But of course, you can't stop developing new features; you still need to make some forward progress in the midst of developing the new app. At the beginning we were 80% rewrite / 20% new feature work. But as time goes on, that balance has pretty much completely flipped; we're now more like 95% new feature work / 5% rewrite. Once we reached a certain critical mass of compatibility, the appetite for finishing the work and completely killing the old thing has pretty much disappeared. And there's a large loud minority that hate change and complain about having to use the new tool vs. the old tool.

FWIW, we were rewriting a Visual Basic 6 application using web technologies. It's VERY hard for me to imagine saying "don't rewrite that VB6 application, just make it better". It's literally not even supported by Microsoft anymore, it was written by one person at the company who has since left, no one else here writes VB6, etc. etc. It was a critical business application, so it wasn't the kind of thing anyone wanted to just leave alone and keep on life support.

Even still, it's hard for me not to wonder if we did the right thing. Maybe we should have just hired a bunch of VB6 contractors to maintain the application and continue adding functionality to it. Maybe moving it to VB.net would have been better. Maybe there's some other migration path for VB6 applications...

Anyway, my biggest takeaway from all of this has been: think very very hard (and be honest with yourself) about how long a rewrite will take. Make sure "the business" and you are on the same page about how long that's going to take and making a serious commitment to focus on migrating to the new tool, and if you can, get it down in writing the conditions necessary to kill the old tool. If your users are anything like ours, they're going to have to be dragged kicking and screaming to the new tool, because we all hate change, so if you don't have clear conditions about when you're shutting the old stuff off etc. then it's going to be painful.

This has been a major frustration for me as a UI developer on the current application I work on. The UI is often hamstrung by how the backend API was implemented. There are frequently cases where we stitch together pre-existing API functionality to make something work in a far-from-ideal manner just because it would take longer to do it right and no one is interested.

I hear a lot (and believe myself I suppose) that I would rather hire someone that knows how to learn than someone who currently knows thing x but can't pick up and learn things on their own. But I feel like it's VERY hard to figure this out about someone. It's pretty easy to test how well someone knows a particular technology or tool (given some variance for operating in a high-pressure scenario etc.) but it seems pretty hard to tell if someone can learn new things quickly, and learn the right things. I feel like this is what algorithm tests are trying to do, but I also feel like a lot of algorithms are based on having a key insight into a problem that is, at least in my experience, pretty hard to have when you're in a room with strangers on a timer and being judged, so if you don't know the particular algorithm to apply, good luck. And also it's pretty easy to go study algorithms and hope you remember how to implement DFS if that's what they ask you in the interview. And there is some non-zero value to just knowing about different data structures and algorithms for certain types of work for sure. I don't think many of us web developer types will be implementing DFS ourselves, but I run into issues pretty often where having knowledge about different data structures and algorithms comes in handy.

So I can see the appeal to doing a test like this that has nothing to do with a particular skill, where you're trying to evaluate someone's judgement and how quickly they can absorb new ideas or figure something out on the fly etc. BUT, I just think there are too many factors that can really muddy this up, and I still don't feel like there's an objective way to measure "smart and learns quickly". Even "learns quickly" is somewhat vague; I personally wouldn't expect someone to pick up, say, functional programming in an hour just by saying "go read about it." Some things take longer to learn than others.

Anyway, there's no silver bullet. I still feel like we end up making pretty subjective decisions about other people when interviewing them. I don't think we're even all that aware of them ourselves. I would say though that if you're interviewing somewhere, you're getting useful information about that place by how they interview you, and so I wouldn't feel too disheartened if you feel like the interview is unfair or doesn't work for you. That's probably a good sign that you wouldn't enjoy working there anyway.

We use Ag-grid at my company. It's probably the most fully-featured data grid I've ever worked with on the Web, but it definitely has some pain points. I think it basically supports almost everything mentioned in this article out of the box (except for modals etc., which shouldn't be part of the grid itself anyway...). They even recently added support for charting selected ranges of data from the table.

Be forewarned though: if you're trying to use this from React with dynamic data that can be modified on the client, you're probably not going to have fun. Ag-grid is a vanilla JS library with a very thin React wrapper written around it, so even though on the surface it looks like it fits into the React model, most complex things you'll want to do end up meaning you have to use the imperative table API. I can't speak to how it fits in with other frameworks out there, but I would imagine it's going to be a similar situation.

That being said, if you're just going to drop some data into the table that's read-only, i.e. just for analysis etc., I think it's pretty solid and hard to find something with anywhere near a comparable level of features.

Agreed.

> The way this code was implemented, the code blocks the page from loading for 250ms, resulting in a much slower internet experience.

Of all the things to complain about that load on almost every web page you visit this seems like the least of your worries.

I agree this is in poor taste, pretty annoying, and could be leveraged to dupe unsuspecting people into coughing up their Xfinity credentials, but complaining about it slowing down page load is like complaining about the heat in hell.

Yeah, this. At my current company, which I would consider large (20k+ employees) and bureaucratic, we've actually gotten this part right. Managers in no way control what the team is working on or deadlines for that work. They behave more like career coaches and therapists. They DO ultimately have control over your career, and I feel like that's a part here where having a good manager matters. But it's very rare for them to step in and shape the teams sprints etc. This is all in my own experience, so it probably depends to some extent on the department you're in and your manager in particular, but I can say this is all true for every team in my department.

The managers are held accountable by their bosses, but usually what this boils down to is teams not doing what they said they would. Which of course happens from time to time because as the article mentions we're all pretty terrible at estimating and shit happens sometimes. It makes me nervous to think about changing jobs because it sounds like this is NOT the way it is in most other places...

Same. I'm just horribly bad at self-marketing and generally have zero interest in getting attention. I used to think that as long as I was doing good work people would notice, and sometimes if you're lucky that can happen, but there are lots of situations where you're doing yourself a major disservice if you're not selling yourself and your accomplishments. You just shouldn't depend on any one else to advocate for you.

That doesn't mean it's easy though. I still hate it and have to make a conscious effort to market myself.

Maybe I'm just missing the point of his article then. The way I read this though is "hey there are lots of devs out there who never post on social media or write blog posts. That's because they don't care about technology or being on the cutting edge, they just do their jobs and go home." If we disagree on that point, fair enough, I might be projecting some of my own angst here.

Yeah, I agree, although probably even a few years ago I wouldn't have to be honest.

I think there's just a lot of black and white thinking going on around this stuff, I.e. you're either this or that (I.e. cutting edge rock star or old crusty dinosaur...) and I just don't believe that's how it is. It's multidimensional and we're all on the various spectrums somewhere and we should stop putting value judgements on which side of the spectrum is better or worse. We all do very different things with very different requirements, so stop prescribing what's best for everyone.

Chris Coyier's The Great Divide (https://css-tricks.com/the-great-divide/), although nominally about front end development, does a pretty good job explaining this problem, and I don't think this is unique to FE at all.

I don't think the point of his article is that this is a "problem" to be solved. And personally, I don't think these people owe you anything. Twitter etc. are all open platforms, there's nothing preventing your stuff from being seen by others.

The fact that you go mostly "unseen" online seems completely orthogonal to whether you love programming and keep up with the latest technologies, etc. I would consider myself "dark matter" in the respect that no one knows who I am and I'm not constantly blogging or tweeting about stuff. That doesn't mean I'm not interested in, passionate about and highly competent in technology. I find it kind of insulting actually that someone would assume that just because I'm not loud about it means anything else about how much I care about it or how good at it I am. I'm not totally surprised by this though; for most people, if you're not jumping up and down telling them about how awesome you are they have no way of knowing. I see this a lot in my current job; all the developers know which of their colleagues are kick-ass at their jobs, but you have to sell yourself and your accomplishments to everyone else.

TL;DR, I know this is an old article, but it seems there's still some perception that us dark matter folks are all just passionless drones in it for the paycheck, and while there's surely some percentage of us for which that's true, I think it's completely wrong-headed to assume that's how we all are.

Does anyone have resources for other shortcut calculations for similar things? This particular one comes up a lot when speaking with my wife's family (they're from Mexico) but I've never tried to come up with a shortcut before. I'd love to see links to other resources, or recommendations for Math tricks for doing quicker mental math.

I don't feel quite as strongly as you, but I generally agree. I don't mind if the person is picture-in-picture-style in one of the corners, but I really would rather see something useful on the screen vs. just the person talking to me.

I feel the same way as the parent, and I would say I have a strong preference for Video. I wouldn't need crazy production value, even if you just did something Khan-Academy-style and wrote down terms and showed diagrams of how some of this works it would help me a lot. I found your article pretty interesting but also pretty overwhelming since I'm not fluent in this area.

My next preference would be something like base.cs (https://medium.com/basecs) where, similarly, you at least define terms and draw some diagrams. I find it much easier to follow this stuff when there's something to look at with relations etc.

While I love podcasts, I find learning anything like this pretty much impossible by listening to them. This is partially because it's harder for me to always follow the concepts just by listening, and partially because I'm usually only somewhat engaged (I'm exercising, or driving to work, etc.).

But, maybe I'm also not your target audience, because I have far too basic an understanding of this stuff, so take it with a grain of salt.

> Node.js, as a language, is almost worthless without its immense open-source ecosystem. You won’t find any real-world applications running on Node without the use of dozens or hundreds of npm libraries simply because Node is not useful in and of itself.

Nonsense. It's a general-purpose programming language like any other. JavaScript isn't my favorite language in the world, and I agree that there are a lot of packages that make working in it a lot nicer, but come on.

Someone at my company recently showed us blueprints in Unreal engine, and everyone there (mostly web developers) had a blast having them mess with different things. The presenter started with the FPS template I believe, and then we were throwing out ideas of things to do, i.e. create a launch pad that throws the player into the air when they walk over it, etc. You would probably score huge bonus points for relating it to things in Fortnite etc. I would have eaten that stuff up as a kid if someone showed me that stuff.

I had the same experience...at IBM. Still the biggest company I've worked for and the least bureaucratic. I know that this was pure luck based on where I landed but I think big companies often get a bad rap and people assume that there's one culture so it's good to put it out there.

I've had subcontracting roles like this in the past. Still not zero interaction, but if you build a network of strong people and you're known for getting shit done, what I've found is other developers that know and trust you are more than happy to subcontract work out to you, and that tends to be very low-overhead from an interaction perspective. The last time I did this, I had zero contact with the actual customer (which can be a downside to be honest sometimes); the dev with the contract and I would just sync up so I knew what I was supposed to be doing and I would just go off on my own and get it done, then we'd sync up for the next thing, rinse and repeat. In my experience, as long as you get along really well with the other dev(s), this is pretty close to what it sounds like you're looking for. But this does require building up a network of people who are willing to subcontract you out work, which isn't always easy.

I think there's a very large scale of "corporate" crap though, and so why not seek to be on the low end of that scale? I've worked at a bunch of companies at this point, and I can tell you for a fact that there is a big difference in company cultures and the amount of bullshit you have to deal with. My current company, for example, is around 20k employees, and the bullshit runneth over. The last company I worked for never got above 40 people, and while there was still obviously some stuff that wasn't perfect, there was almost zero bullshit to deal with.

Just as an example, at that job I still interacted with people quite a bit, but almost non of it was mandated; people worked together to get shit done, and were trusted that they could reach out when they needed help etc. At my current company, it's all lowest-common-denominator; everyone has to use the same processes because some people will just sit around and do nothing if you don't make them tell everyone what they're doing all the time.

Anyway, to the op, I would say that you probably won't find something with close to zero interaction, but I do think you can absolutely find places where the vast majority of the interaction is fruitful.

Ugh, I'm living through this right now on an app I've been working on in my company for 3 years. Someone will create a user survey that gets a 5% response rate and use it to justify/rationalize some decision. They think that since they ran the survey they now have data that is good enough to base a decision, with zero desire to statistically validate whether that data is any good or not.

I can't remember which thread this came from, but this talk was posted here somewhere on HN recently and I found it pretty interesting and relevant to this sort of thing: https://www.youtube.com/watch?v=TGGGDpb04Yc

I don't know this for a fact, but I always assumed that it was just to create a false sense of urgency around your booking.

Depends on your area. I live in a small town and there just aren't that many people you can meet. Maybe there's an online mentoring site to connect people out there?

Cryptonomicon is one of my favorite books of all time (I'm probably due for a re-read at this point).

I would also recommend "Seveneves", one of Neal Stephenson's most recent books. "Anathem" was also very enjoyable.

Could you elaborate on the "gross things"? I read Disrupted and thought it was pretty funny/interesting and I've watched a few of Dan's talks and enjoyed them. A quick Google search didn't turn up anything about him recently though.

I did sort of wonder how accurate some of this stories were about HubSpot, since you're only hearing his side of the story and the more sensational the stories the better the book...