I understand that some people prefer to work from home, but there seems to be a narrative that every single one good software engineer is in that camp, and I honestly don’t see where this belief came from… I very much miss the days where I could meet all the junior members of my team in the office and quickly sort out whatever was blocking them etc.
What prevents you from quickly unblocking people remotely? Genuine question; I keep hearing people saying similar things about junior team members, but I don't understand what the remote issue is with them in particular.
Sending a message can be a big hurdle when you’re new to a job. A junior person likely has a very deified view of senior team members and believes that their time is sacrosanct. Encouraging junior people to “just ping me” is like telling an arachnophobe “it’s just a spider”.
If you work with someone in an office, natural opportunities arise to grab some time, whether it’s when they’re bumbling around the office, grabbing something to eat or walking from a meeting.
A remote company can create an environment to address these problems, with structured time for conversations but it is very difficult to get right.
I am a fan of both remote work and in office work. Remote work is cheap and has little margin for error; in office is expensive as it is paying for guard rails that make it (relatively) difficult to get wrong.
I don't find it difficult--I regularly book time to do pair programming over Tuple with everyone who's up for it on the team. That's in addition to taking opportunities to chat on Slack about anything they're working on, e.g. PR reviews.
What I've seen work is for the team to have a private channel, and whoever isn't in the middle of something can answer, and the whole team will see that answer sooner or later.
Colocation gives you a) passive source of information (e. g. just by observing people, see them being frustrated or cursing) and b) lower barrier to get talked to. Both can be disruptive for your own work, but facilitate more communication. You yourself can be more proactive, but that doesn't solve the problem on the whole team / organization level.
The thing that I see happening is that someone remote is stuck in a spiral of XY problems and there isn't as much serendipity to talk about it with someone -- nobody is there to see that you're exhibiting signs of frustration while also knowing the problem you're working on is simple
Well when I have some free moments I like to walk around and stop by grad students offices and see what they're up to / make suggestions. I'm not gonna do the same thing on slack...
I honestly don’t know the answer, I guess this is exactly what this whole debate comes down to. In theory all the tools are there, in practice people see very mixed results.
I've never seen it suggested that all the best prefer WFH, only that statistically more of them leave when they don't like any new mandate. The way it works out is that the better devs are more mobile and more likely to get employment where the working environment suits them.
Yeah there are clearly tradeoffs, neither side's zealots seem willing to admit it though cause the stakes are so high so the conversation remains fundamentally dishonest.
The debate isn't really about whether home or office is better, it's about who should have the power to weigh and make decisions about those tradeoffs: employer vs. employee. I think most of the professional class are loath to think about it that way because it sounds suspiciously like the beginnings of a labor movement.
There's definitely a lot of cowardice and fear underlying the capital class's current strategy of "remain in limbo until forced to move." Maybe it's fear of losing that crucial employee that keeps the light on, maybe it's fear of employees waking up to what exactly a job is and what's expected of them (compliance for 40-60 hours a week of their lives) and becoming demotivated.
It certainly doesn't seem to be fear that allowing WFH means they will lose their competitive edge in their industry. Agree it's more about the capital/labor relationship potentially fraying.
The labor movement LARPing you see every so often online I think is ridiculously premature. The labor movement at the turn of the century was ridiculously volatile and borne from a ton of unrest. It's a ways away.
This is not about preference about where you work (ie maybe not all good engineers prefer WFH). This is about fkexibility ane accountability. People don't like being jerked around. Don't like being forced to do stupid things that don't matter. The better you are at your job, the more options you have. When you have options you don't have to stand for this bs.
The problem here is that if the idea of using debuggers becomes an unfashionable niche then the next language won’t provide one at all.
Given how great Java/C#/JS debuggers are, one could hope that every new language will ship with a working debugger, that it would be table stakes.
But there’s a whole generation of working programmers that started their careers in Go and were told debuggers are lame all along, so it’s hard to blame them for not using one.
As for fashion and being told what is cool - I do not give a flying fuck about propaganda. I use what I think fits me and provides best ROI (I am my own business and pay all the expenses).
I am very much in the opposite camp, I am 10x more productive in tech stacks where I can use an interactive debugger.
It’s not that I enjoy stepping through code line by line, I rely on a debugger to verify if my assumptions about “starting conditions” of a certain piece of code are correct and, if so, at which point my understanding of how things should be no longer reflect reality.
This can all be done with printf, if you knew ahead of time what you want to print. But most of the time I don’t, the whole point is that I do interactive exploration of the program state (“evaluate expression” is the main feature of a good debugger). When I find a problem I dig deeper, which is a lot faster within a debugger session than any recompilation loop I’ve ever seen (even in Go).
In similar spirit I play with SQL queries when given a data set that I need to extract something from.
It's worth pointing out that Kotlin's standard library contains a type called `Result` with a slightly different API. Also a function called `runCatching`[1] that uses it.
This. The article and most comments here assume that getting a degree is prohibitly expensive, which is the case only in one country in the world. If you happen to live in that country, consider studying abroad.
Considering the recent "Spectre is here to stay" paper [1], can anyone comment on whether Firefox should be considered secure until the work on process-per-site lands (I believe they are working on it)?
I think this is the biggest gap in the Haskell ecosystem right now. Every time I try to write something in Haskell, I remember I cannot "talk to my program" easily and just give up.
You can use JVM debugging tools and with a guide on how to interpret the results for Eta (or a tool that does the mapping to Eta source code for you), debugging can be pretty awesome. The implementation was specifically designed to re-use the JVM Thread stack as much as possible so that you can get stack traces and figure out the source of the error. You'll get stack traces similar to other JVM languages like Scala and Clojure. See http://eta-lang.org/docs/html/eta-user-guide.html#debugging-... for an example. You can use tools like slf4j-ext as java agents and get nice traces - it's how I debug the Eta runtime.
I, for one, agree with this kind of hiring process.
From my own experience - people that do well in such interviews are good generalists. On their own they will start discussing performance improvements and ways to parallelize the solution, it's a pleasure to have such an interview.
It's about enjoying problem solving and willing to keep your brain fit. It has nothing to do with memorizing solutions to some existing set of problems.
