• 0 Posts
  • 26 Comments
Joined 1 year ago
cake
Cake day: June 8th, 2023

help-circle

  • I agree. I think we elevated Computer Science’s importance early on in the industry, and that has stuck around. If you’re a University researcher trying to make a better compression algorithm or whatever, then yeah you’ve got a lot of overlap with mathematicians. But if you’re out in the industry building CRUD apps to fit some business use case, all that theory isn’t going to matter much in your day to day.

    It’s still just one of those mostly-bureaucratic hurdles where you need a CS degree to get your first job, and you need to be good at math to get the CS degree.

    That said, there are definitely crucial moments where regular projects can still hit scalability boundaries, and a solid understanding of math and CS fundamentals can get you through that. Every single developer doesn’t need to know that stuff, but it’s occasionally good to have access to somebody who does.


  • Depending what you don’t like about math, it might or might not be an indicator. If you like problem solving and understanding why math works the way it works, but hate the rote repetition a lot of schools use to teach it, then you’ll fit right in. That’s how I was at that age. (Disclaimer: I’m old now. They’ve changed the way they teach math a few times I think. I’m not sure if my experience is directly comparable to kids in school these days)

    Similarly, don’t look at schools that teach Computer Science and conflate that with what it’s like to be a developer. Most real dev work is totally different. CS fundamentals help at times, but aren’t as big of a deal as CS programs would have you believe. (Again, I think there’s a wider variety of educational options these days too. In my day you had to get a CS degree just to get a recruiter to talk to you, even though it was mostly inapplicable).

    Why are you interested in learning lisp? Some hobby that requires it? A potential career? Tell us more about the career and maybe we can share knowledge about how mathematical it is.


  • Also, there were some candidates who managed to get 95% and above — but would then just be absolutely awful during the interview — we would later discover that they were paying someone to complete the technical test on their behalf.

    Yeah my company shot itself in the foot by replacing technical interviews with an online test and hiring a bunch of cheaters. After a while we started doing a zoom interview where we’d go over the code they supposedly wrote and ask them to explain it to us. Even that simple step made it obvious who had or hadn’t actually written the code they were talking about. I’m pretty sure a few candidates had somebody talking in one ear and/or typing to them on a separate screen.



  • This is one of the things I talk about when people ask what the difference is between junior and senior developers.

    A lot of security is just box-checking. A lot of it is hypothetical and relies on attackers exploiting a chain of multiple bugs that they probably won’t ever find…. But you still gotta fix it.

    There’s no point in being so proud of your code and dismissing security concerns because you’re arrogant enough to think it can’t happen to you. Just learn to fix it and move on with your life.




  • I use a “real name” domain. My last name ends in the letters “in”, so I bought a .in domain, such that the domain name is my last name with a dot in it.

    Can’t honestly recommend that approach. It’s a cute gimmick, but when non-technical people ask for your email address and it doesn’t end in a TLD they recognize, their heads explode. I usually give out my gmail address.




  • Way too many other meetings. Meetings all the time.

    There was a nice period where we had 2 meetings a week. One team meeting, then one social happy hour meeting with just the devs and no manager. (Mostly so we could complain about the manager, but general social bonding also). We also did plenty of ad-hoc meetings as needed, but generally the two regularly scheduled ones struck a good balance of getting things done without wasting time.

    In hindsight, that manager could be a difficult person to work with, but the overall balance of trade-offs was way better with him than it is now. Very few, very efficient meetings, were one of the positive tradeoffs for sure.






  • My salary, I guess.

    Everybody on my team is required to do on-call once they have enough experience (except for the low budget offshore contractors who I wouldn’t trust to do it anyhow…)

    We have 2 people on call at a time, 1 primary and one backup. You do a week on backup, then the next week you’re primary.

    There’s no set time limits etc, but if you get sucked into some fire, people are reasonable about letting you take some time off the next day or whatever.

    All in all, there are very rarely fires that happen inside or outside of normal working hours. Making the whole team be on call helps incentivize everyone to write more stable code since it’s your own ass on the line.



  • Ephemeral test environments are a great tool for this kind of stuff. We do work on a feature branch and spin up a test environment for that feature. QA happens there, then it gets merged to master once they approve it.

    In our workflow, it deploys immediately, but you could just as easily adapt that to cut a release every Thursday. Then each release can just contain whatever makes its way into master by Thursday. You might need to add more process if there’s release notes etc that need to be coordinated. My suggestion on that would be to cut the release on Tuesday or Wednesday, then whoever does that documentation can look at what made the cut and spend a day documenting it, then just press the deploy button on Thursday once they’re done.


  • Yup. Nothing wrong with pushing up a draft PR and asking for feedback; but definitely need to be an active participant in fixing the issues, not just expect somebody else to do your work for you.

    That does lead to some sticky inter-personal situations though. Like there’s people on my team that I trust enough to just rubber-stamp a PR that looks good but doesn’t have test coverage etc. Can generally trust those people will let me know if the failing tests uncover some substantial work that needs to be re-reviewed.

    There’s other people I don’t trust and will insist their build passes before I review it. Once that person notices they’re being held to a different standard, it can be difficult (but necessary) to have a conversation about what they need to change in order to earn that trust.