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.
You've still mixed the logic, just in a horrendously oblique manner. If you rendered the list twice the second list's running totals would be wrong from re-use of the global variable (in what is meant to be render-only logic).
If you're after keeping the concerns separate you would need to precompute the running total for each item.
See also: mustache(5) which completely embodies this philosophy.
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've even worked on a number of projects where
a) the unit tests used an in-memory database
b) dev environments used mySQL/postgres/SQLite or similar
c) production used Oracle or SQL server or similar
Good luck doing that with hand-coded SQL.
But for me 99% of the benefit of using an ORM is compile-time checking of queries. I don't see why in principle that couldn't be possible using raw SQL, but I don't know of any good examples of it.
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.
This is another piece that I never got to talk about in my post. There's a LOT of software in trucking, the problem is that most of the software was built in a different era.
Platform Science looks pretty cool - seems like a TMS with specific improvements against legacy systems. Building a TMS is a pretty good business - massive fixed cost but once you've built the system, it's fairly hard for competitors to dislodge you.
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.
How were you able to write a book, I mean it's a lot of writing. How long did it take you to write the whole thing. Did you use some special program? How did you publish it? How did you plan your lessons or chapters?
> How were you able to write a book, I mean it's a lot of writing
Although I'm not the OP, it can be less daunting if you split your topic into an outline i.e chapters. Then outline each individual chapter. Before you know it you've got a book ;)
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.
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.
