Disagree. I would argue your example is hard to read compared to the equivalent in Vue, and it mixes business logic (computing the running total) with the rendering logic.
I think the bigger reason it is banned at most companies is because it's nearly impossible to know what kind of license the generated code is available under. Copilot is trained on open source codebases, which carry a number of different licensing agreements to use that code in your own codebase. Companies simply do not want to deal with using software that opens them up to unknown legal risks.
Tracket is a platform that lets you build, customize, and monetize niche job board websites. Our platform empowers ambitious entrepreneurs to create professional, customizable job boards and monetize them to bring in extra income.
We're looking for feedback on our onboarding flow and how we can make it as easy as possible to get a job board up and running quickly. We're also looking for suggestions on how to make our themes more customizable and easier to use.
Prisma is good for writing simple selects, updates, and deletes. But the moment you need to write any kind of advanced query with joins, nested queries, unions, etc. it gets frustrating very quickly.
Kysely and Knex are far more flexible for writing complex queries and don't get in your way.
No, you may never have had to switch databases, but I have worked on codebases where we've had to switch databases, and I'm sure others have to. Most likely when dealing with monoliths where you can't do a full re-write and you can't break out a separate service for various reasons. The repository pattern is your friend in these situations. An ORM should ideally be able to read/write to multiple database drivers which makes this easy by dual-writing to both databases from the repository layer.
I work for a startup in the trucking space so it's nice to see such an in depth analysis of the industry. I can agree that most of the article is accurate based on what I've seen in my 4 years in the industry. There is so much more innovation going on in the trucking industry that a lot of people don't know about.
My company, Platform Science, is building a configurable open platform that connects a lot of the different categories mentioned in the article (drivers, carriers, brokers, OEMs, software vendors, etc). If you're interested in career opportunities in the trucking industry, we're hiring for a number of open positions[1]. Feel free to send me an email (My work email is in my profile) and I can connect you with the right hiring manager.
Mostly through posting valuable content on the newsletter and sharing it across various channels, as well as comments like this where I can plug the book and newsletter in the right context.
It also helped that the book was published on Holloway.com, and they had their own audience that they have been able to promote their titles.
Not your typical side project but my book, Junior to Senior, has been averaging over $500/month in sales since it was published back in October of this year.
I've also been growing my newsletter, Beginner.dev, to help reach my target audience for the book and teach them the importance of soft-skills for software engineers.
I also have a job board for junior software engineering roles in the works to add even more value for the book's target audience.
Aside from my full time career as a programmer, the best side income stream I've built has been my book I wrote[0] to help software engineers develop the soft-skills that are necessary to reach a senior level position.
I spent 4 years on and off writing and preparing the book for publication, and it's been bringing in a steady stream of income since it was published in October 2022.
While I agree with the general argument in the article that sales data and similar metrics should be public, I think there's a lot more that can be done to unlock all of the knowledge stored in books. There are vast amounts of knowledge that humanity has built up over centuries that are either hard to find or hard to access unless you know where to look. How does someone like me discover that knowledge for a topic I'm interested in?
I wrote a book that was recently published to help junior and mid-level programmers build up their soft-skills to advance their career[0]. The book was published by Holloway[1]. They have an interesting platform to solve this problem, which is why I chose to publish with them. They publish works primarily through their online reader, which is indexable by search engines. So someone searching for "How to get up to speed on a new codebase" in their preferred search engine could stumble across the chapter titled "How to read unfamiliar code"[2] and read a free preview of the book. Over time, people can discover and access the knowledge stored in any book that is published on Holloway's platform.
Another nice side effect of the platform is that it can be updated over time, so outdated knowledge or content can be revised, updated, and re-indexed by the search engines as knowledge about topics evolve.
If you're considering writing a book, or have a manuscript and are looking for a publisher, I'd recommend giving Holloway a look to see if it would be a good fit.
Some really good advice in the article, and I like the examples too. I agree with the author that communicating effectively is an important skill in a developer's tool box, but the article only covers written communication. In reality, effective communication involves speaking and listening skills as well. These skills are important enough for developers that I wrote a whole chapter on communicating effectively in my book[0].
Here are a few more points I think are helpful:
* Communicating isn't just saying something. People might not understand your ideas, or they may interpret what you're trying to say in a different way. Sometimes you need to repeat yourself in order to drive your point across, and you may need to communicate your idea in multiple ways for people to really understand what you're trying to say.
* If possible, try not to communicate through other people. Don't ask Tim to ask Alanna to do a favor or a task that you need to get done. It may feel like good delegation, but the more hops your message takes before it reaches its destination, the more chances for the message to get distorted, like a game of telephone. Try to communicate your message directly to the intended person if you can. Sometimes this isn't possible and you need to communicate through other people though.
* Understand the audience you're communicating with. Are they technical? Then it's okay to use technical jargon and concepts. Are they not technical? Try to use more common terms and phrases. You may need to come up with examples and similes so it's easier for them to understand something that's technical or abstract.
* Clear writing is critical in code reviews. If you think a line or block of code needs to be changed, explain why in the code review, don't just say it's wrong and it needs to be changed—that's not helpful. Especially with younger engineers that could benefit from understanding why their code could be improved.
* If conversations turn in to long discussions on a code review, move the discussion to a video call or in person conversation. No one wants to follow a thread where two developers are arguing about whether something is right or wrong. Settle the disagreement outside of the code review.
* You'll be writing a lot of technical requirements in your project management system as you get more experienced and lead more projects and features. What you write in the ticket won't always get interpreted exactly how you think it will, so try to write as clear and thoroughly as possible when describing what needs to be done. Sometimes you may need to describe how it needs to be done as well if you'd like it done a specific way.
Hard to say without know how your team cuts a new release, but my guess is you'll want to track all these changes in your project management software. How do tickets move through your system from planning -> analysis -> dev -> QA -> production?
Your release process should in theory only be picking up changes for tickets that have made it to QA and are tagged as QA or passed QA in your project management system.
That's some great feedback, thank you! I'll add these to my notes for the upcoming revisions.
There's a section about having a "team-first approach," but I agree with your comment that mentorship is another trait that could even deserve it's own section.
We're planning to make some revisions to the book based on some of the early feedback we've gotten, so for now the Holloway reader is the best place to read the book. We do plan to offer PDF and ePUB versions in the bundle in the future though.
Thanks for the feedback. Holloway's platform makes it easy to make revisions, and I plan on updating the content periodically based on feedback like this. Comments from readers in the book itself also help as well to adjust the content over time.
I had a feeling this topic would be a bit controversial on HN :) I tried to address this in the book in the first section of "What Makes You a Senior Engineer?" by talking about the different meanings, and how the software industry doesn't have a standard definition of what a senior engineer role entails. Everyone will have a different opinion on what makes a senior engineer, so I'll try to add more info about the nuances involved in the senior title in future revisions.
The kindle version will be release in the future, hopefully soon. We're planning to make some revisions to the book based on some of the feedback (as well as adding/updating the links at the end of each section). So in the short term, the Holloway reader will be the best place to read the book as these revisions are made.
Pretty sure you should be able to download it, but I don't see the option either. I've reached out to my contacts at Holloway to see if there's a reason why the download isn't available.
Hmm, I believe you should be able to download it. I've reached out to my contacts at Holloway to see if there's a reason why the download isn't available.
Thanks! And congrats on your book as well. It turned out to be way more work than I imagined, but it was worth it. I ended up learning and growing as an engineer myself during the whole process. Getting the right words down on paper really forces you to organize your thoughts and clarify what points you're trying to make.
I'm hoping this helps junior devs focus on the soft skills earlier in their career, rather than putting them off until they're ready for the promotion.
Thank you! I agree, there's plenty of resources out there to learn how to code, but there's a lot that goes into being a professional programmer than just writing code. I'm hoping this will be a good resource for developers working towards their first promotion.
No need for a computed property. Plus, getRunningTotal can be unit tested, or extracted to another file for reusability.