- caseymarquis parentThat's either a fun or terrible exercise depending on who is administering and how. However, if you said it's a Ruby role and the candidate is good enough to be picky, you may scare them off when they think your description of the role was a lie.
- I recently used ChatGPT canvas to improve a friend's resume. I had managed him in the past, and he is great to work with. However, from his resume you would never know it. I did 3 hours worth of editing and improvement in 5 minutes. I gave rambling descriptions of what he had done when working for me and why it was impressive, and GPT translated this into resume speak almost instantly. I then gave some vague suggestions for improvement, made a couple minor edits to buff off the AI veneer, and viola, he had a professional resume that will help him do great work in his next position.
- While LINQ does include a library of extension methods for functional programming with .NET collections (which is great), it also includes "Expression Classes". In a nutshell, this allows a user to pass a single expression lambda to a function, and the function implementor receives the abstract syntax tree for the lambda, not the lambda itself. You can then not only receive and analyze these trees, you can also manually build and compile them. This effectively allows a limited set of runtime macros within .NET.
- I've been occasionally mentioning this book on HN since I read it. Linked below. The book is about how companies evolve and how teams of people work together. It uses human growth as an analogy and fairly accurately describes how companies fail or thrive at different stages. It's older at this point, but it's about human behavior and group dynamics, which don't change rapidly.
The book doesn't use the phrase founder mode, but it discusses the transition from a founder oriented company to a culture oriented company in detail.
The human analog works well here. Advice for parenting a baby, toddler, child, or teenager is all different. People's needs change over time. At a certain point people become adults and need mentoring more than parenting.
Almost every article on how to run a company fails to qualify the stage of growth that the company is in. Once you start thinking about how companies evolve over time (somewhat predictably), it changes your perspective. PG is right in the correct context. Those advising AirBNB are also correct, in the right context. Following either piece of advice blindly is just living in a cargo cult.
https://www.amazon.com/Managing-Corporate-Lifecycles-Ichak-A...
(Like any business book, it's at least 20% BS, but the remaining 80% is quite good. If you do read the book, do not read the first few chapters and assume you've gotten the whole idea. The book has a very good paradigm on worker profiles and what is needed in different stages of growth in its later chapters.)
- I grew up working construction on the side with my father, became an appprentice lineman, moved to aftermarket electrical installations in CNC machines, then ended up writing software products for over a decade. I've worked on a wide variety of software: Embedded projects requiring 2000 line assembly ISRs for legacy RS232 protocols, reverse engineering binary network protocols, implementing network server protocols from specifications, writing my own actor and dependency injection frameworks in managed languages, web application backend work, frontend work with JavaScript/TypeScript and frameworks, and so on. I also do a lot of product management, support, customer management, and internal management. Much of my customer support involves teaching external developers from large corporations how to use HTTP and SDKs.
I'm usually one of the smarter people in the room when doing software development and spend a lot of time helping others. In construction, I'm the enthusiastic idiot as the skillset is different. Most tech workers underestimate how high skilled tradework and many other positions outside their experience are, especially management work.
Having said all that, I feel uniquely qualified to offer a rebuttal. The article is describing a clear pattern that I see at large companies that are not focused on software development or lack solid engineering leadership. Ironically, the problem gets worse the more a company tries to outsource IT as they face all the same challenges with less control. It is an organizational health issue however, not some universal truth. If tech workers lack anything, it's experience with organizational growth, change, and group dynamics, not construction experience. Organizations are like people, they grow, change, figure out who they are, have identity crises and need different things in different phases. Ask the highest level/most competent manager you have access to for book recommendations if you're interested in this.
Anyway, back on topic, software "gruntwork" typically implies a department lacks the agency to automate away said gruntwork or lacks the skills to do so. As an example, I work with many organizations using the JVM, but none of them use Scala, Kotlin, Clojure, or any other "nice" JVM language. They use Java. In some cases Java 8. If you're writing Java, there is absolutely stupid gruntwork. I've written example applications for some of these organizations and I had to create code generation tools to stay sane in this environment. In software, you eliminate stupid gruntwork with tools, not people.
We do need average enthusiasts in software development, but it's not the same as construction. In construction the less talented person fetches things and does setup work. In software development, the less talented workers spend most of their time using libraries, plugins, frameworks, compilers, interpreters, databases, and languages while the more talented workers write them.
My experience isn't universal, and I'd be interested in hearing some dissenting opinions on this.
- I thought it was more like 2^23 unique prototypes?
- I think OP has solved some of those issues with this approach. Initially, this is a fun tool that provides value to individuals. The result at scale becomes extremely valuable. The biggest missing piece is verification of skillset. I'm not sure how to solve that. Current employers? Motivated to keep their top performers and little incentive to engage early on. Peers are easy to game and are susceptible to generative AI for automation. You would almost need to integrate some kind of in person meeting for verification. Establish known experts and have them review and verify, then feed that into employer feedback after hiring for a sort of credit system. Employers using the rating system would themselves need to be monitored and policed.
- This is a very interesting idea. Given access to long form descriptions of what has been worked on, ideally with some kind of trusted verification, this approach seems like it would operate at scale quite well and could transform the way we network and hire. A technical expert could explain what is needed for a role, and with AI assistance candidates could be sorted through extremely effectively and matched to companies that are a good fit for their experience. Given, this doesn't account for junior developers who have yet to build up their skillset, but for experienced developers this could result in a much more efficient hiring process.
- Men are applying and women are hiring. Half the candidates are lying on their resumes. Many candidates are spamming their resumes indiscriminately. If you've ever had to hire someone for a position that attracts hundreds of candidates (i.e. software engineer with decent pay), you'll encounter the same dynamic. I hate being in that role. I have to reject 199 people and accept 1. Often, there are dozens of qualified candidates. You interview half a dozen, and then you tell 5 out of 6 perfectly qualified people you interviewed they didn't get the job. You feel like a horrible person the whole time. I've discussed this with my wife (we met on Bumble) and she confirmed the scenarios are very similar.
It's often better to be in the hiring position than in the applying position. But it's awful for everyone involved.
The way to avoid this mess when applying for jobs is to build up a network and lean on it for new positions. I wonder if dating may have a similar alternative approach.
- Comparing a JavaScript ORM to a C# ORM like Entity Framework feels like comparing C macros to Lisp macros.
You can't really have a reasonable conversation about ORMs without defining the feature set your ORM has. If an ORM doesn't apply type safety to SQL queries and translate typed code expressions to equivalent SQL expressions, it's not performing two of the key functions I associate with ORMs. If I didn't take these features for granted, I would probably question how useful ORMs are too!
I think the reason it's so hard to have a conversation about ORMs in general is that we're often lumping radically different systems together and then making a blanket judgement. Again, it's like working with C macros, getting annoyed with them, and then judging all macro systems to be bad.
- Since the word agile has become so loaded, you can instead explain why a waterfall practice is linked to predictable problems and avoid buzzwords entirely:
It takes 6 months to act on customer feedback with our current release strategy, and a full year to fix the bugs related to that feedback. We should be rapidly iterating on feedback quickly to avoid churn. Let's try xyz...
- That seems positive, honestly. It forces a focus on the developmental process over the finished product.
- Please write a blog post about that when you get a chance to do it!
- Interestingly, it might be easier to replace mid-skill artists than mid-skill developers (not to say both won't happen over time). The key difference is that when generating art, you can say "Make A in-the-style B.", get what you want, and move on.
Meanwhile, you have to live with the consequences of AI generated code.
Case in point: My wife was trying to build a system to generate POs per vendor from a series of workorders a couple weeks ago. She was using AirTable, which vastly simplifies the creation and use of relational databases. Given a lack of database experience, the structure that she made was misaligned with what she actually needed (and completely denormalized). Putting it into production would have caused major problems over time.
This made me realize that writing code is only one of the barriers to entry in software. Eliminating this barrier effectively gives everyone in the world access to a small team of incredibly junior developers who have no idea what they're doing.
Just like mismanaged DIY home projects create more work for professional contractors, I think AI might -oddly enough- create more positions for mid-tier and higher developers.
- I migrated from vue 2 about 4 months ago seeking better typescript support and looking to move away from webpack. While I absolutely loved the simplicity and feel of svelte, I came to the same conclusion that it is not ready for a major production application yet. In a few years, I'm hoping vue setup scripts are as low friction as svelte or it may be time to switch over (they're close now, if you're using the latest macros, which may or may not be in beta still).
- While not all companies are as pervasively fucked up as the article claims, all companies do have problems, and these problems typically correlate to the stage a company is in. There's a great book on this which is older than I am called Managing Corporate Lifecycles. What's interesting with books about people is that they age much better than books about technology. Technology changes rapidly, but groups of people trying to accomplish something go through surprisingly predictable phases, regardless of the time period. If you like the title of the article but were disappointed by the content, I would highly recommend checking out the book I mentioned.
- As an outside company without a relationship with SAP, what's the best way to build integrations with it? What's the path? How do we get access to sandbox environments, and will it cost money? I figured I'd selfishly ask while this is number one on HN and all the SAP gurus are here!
- This seems like it would make a good poll. Could you convert it? My answer is the same as someone else before, and I'd love to get some numbers back on this.
- I'm a huge fan of C#, but I didn't really like Blazor when I tried it. I had expected to love it too. I found much of Blazor's boilerplate to be very ugly, I didn't like the complication involved in referencing npm libraries or backend code, and I couldn't figure out where several magical authentication related pages in the example app were coming from. I switched back to Typescript and Vue 3 (almost went with Svelte). I'm investigating the HotChocolate GraphQL library this week to see if I can marry the frontend and backend that way. I was hoping Blazor would give me a nice productivity boost, but native frontend development is hard to compete with. I'll likely try again in a few years.
- The last time I posted a job ad, 100 seemingly qualified candidates responded within 2 days. I interviewed 7 of them, and 6 out of those 7 were more than qualified for the position. Having lived both sides of this, I feel hiring is very much a numbers game.
- I take it you're not a musician?
- I think this is a little of column A and a little of column B. Just as there are good and bad developers, there are people who are good and bad at running projects and organizations. The author feels that something is wrong. He knows he is not working anywhere near his full capacity and that the organization created this environment. He also highlights a lack of growth opportunities at some companies. What he doesn't do is highlight solutions or recognize why certain behaviors are key in certain environments.
Toward that end, I would recommend three old and poorly written books with timeless and wonderful ideas: The Goal, Critical Chain, and Managing Corporate Lifecycles.
While these books are all about management and running a company, I think they lend perspective to developers on why certain things happen the way they do. They can also help someone recognize and pick a healthy organization to work in. Just like books on software development, these books augment experience, they don't replace the need for it.
- Sounds like a feature.
- I dropped out of high school with a 0.5 GPA, I now own a sizable percentage of a software company valued at a life changing amount of money. I cannot emphasize enough: Do not do what I did.
It has been an uphill battle for 14 years. At every single turn there have been disadvantages, challenges, and closed doors because of the choices I made as a teenager. Highschool is terrible for many of us. Hell, being a child is god awful. Apply yourself anyway. The bare minimum to get a STEM degree at a state school is fine. Don't worry about perfection, just passing is enough if that helps you stay sane. If you really like programming and hacking on electronics (and you're half decent at it), your grades will never matter after you land your first job. Put something cool on github and the right people will hire you for that first position anyway. At that point you get paid to hack on things all day long. It's a blast. Highly recommended.
Everything is ten times harder if you don't hit that minimum standard though. If I could go back in time I would check those boxes.
Final thought: Money has diminishing returns. I use it as a proxy for success above, and it's nice, but I would easily trade places with many of my employees. They work half the hours and spend more time doing the kind of work I enjoy. Once you have enough to live comfortably, optimize for something other than money.
- If your manager doesn't understand that everything being broken all the time is a natural part of development, then you might need to find a better place to work. If someone I managed said "I'm blocked because Webpack is broken." My reaction would be to laugh, tell them we've all been there, and ask them to spend an hour or two on it. If they can't fix it after that I'd start helping. They'd be free to keep trying, or work on something else if they wanted a break.
I will say this though, my reaction to things unexpectedly breaking on me is typically "Oh... interesting." Sure, it can be annoying when it happens at the wrong time, but I also get a little excited. If there isn't some part of a person that thrives on the break/fix process, then software development may not be a good emotional fit. This is a normal part of the job, so if you don't have terrible management and you still hate the process after seven years, maybe look at other options. If everyone was an intellectual masochist that enjoyed things breaking on them, the species would probably go extinct.
- Mostly I'm amused, but otherwise you're pretty on point. As an outsider acquiring VC funding seems very challenging and time consuming. We perform on parity with our VC funded competitors, and 10x growth will make us about 10 times their size. We're pulling this off without the advantages of their funding. I'd imagine we could shoot a little higher than 10x growth if we had millions of dollars to spend. Despite being better positioned with a significantly more effective growth strategy, we are not well connected, and so actually getting that VC money seems like more time and effort than we have on reserve.
- > In today’s startup environment, raising money might be easy
I hear this a lot, but it seems like it's only true for people in specific geographic locations, who are well connected, and willing to pretend their problem benefits from blockchain or ML.
I scratch my head in confusion wondering how some of the VC funded start ups I see got millions of dollars for vague and likely unprofitable ideas. Meanwhile, my software company has an established customer base, has set up contracts that practically guarantee 10x growth in the next two years, and our options for funding that growth are effectively bank loans or working longer hours. At the same time, our VC funded competitors have spent millions of dollars just on office space, and have 15 times our development staff. The world seems absurd at times.
- I'd like to point out that the article isn't disagreeing with you. It's saying inheritance is a dangerous interface for other users of your code (across packages is their terminology). So, if you write a library, maybe don't design it around extending classes. This is a much milder stance than the title implies, and seems pretty reasonable to me.
Edit: Totally with you on boilerplate though. +1.
- I would. I'd actually view someone asking for this as a positive.
- LINQ GroupBy() is the most common use I can think of. I would definitely look into that as it's a nice tool to have. Otherwise, keep them in mind if you're ever pulling data from an external source (SQL, JSON, GQL, Redis, etc) and you're annoyed about having to make a class for some trivial operation.
If a library doesn't have an API for using them with generics, you can paper over that with:
T fn<T>(T throwAway) => Library.Deserialize<T>();