HN user

dglass

674 karma

personal: david (dot) glassanos (at) gmail.com work: dglassanos (at) platformscience.com

Posts59
Comments144
View on HN
newsletter.beginner.dev 2y ago

Striking the Right Balance: Over-Engineering vs. Under-Engineering Software

dglass
38pts48
newsletter.beginner.dev 2y ago

The Art of Abstraction: From Learning to Engineering

dglass
3pts0
newsletter.beginner.dev 3y ago

Who's Hiring Junior Engineers – Edition #3

dglass
2pts0
newsletter.beginner.dev 3y ago

How to perform code reviews like a senior software engineer

dglass
1pts1
www.holloway.com 3y ago

Show HN: My book for programmers called “Junior to Senior” was published today

dglass
183pts38
newsletter.beginner.dev 3y ago

Who's Hiring Junior Engineers – Edition #2

dglass
1pts0
newsletter.beginner.dev 3y ago

Management Is Not Just for Managers: The Path to Becoming a Senior Engineer

dglass
4pts0
twitter.com 3y ago

Booster failure on Blue Origin uncrewed flight

dglass
3pts1
alexw.substack.com 3y ago

Betting on Unknown Unknowns

dglass
3pts0
newsletter.beginner.dev 3y ago

Who's Hiring Junior Engineers – Edition #1

dglass
2pts1
newsletter.beginner.dev 3y ago

I Burned Out

dglass
2pts0
newsletter.beginner.dev 4y ago

Refactor or Rewrite: Things every programmer should consider

dglass
3pts0
newsletter.beginner.dev 4y ago

Iterate to More Complexity

dglass
1pts0
newsletter.beginner.dev 4y ago

Technical Debt Isn't Always a Bad Thing

dglass
1pts0
newsletter.beginner.dev 4y ago

Business Value for Programmers

dglass
1pts0
blog.beginner.dev 4y ago

Navigating an Unfamiliar Codebase

dglass
2pts0
newsletter.beginner.dev 4y ago

Reading Unfamiliar Code

dglass
1pts0
newsletter.beginner.dev 4y ago

How to Ask Better Questions as a Programmer

dglass
1pts1
newsletter.beginner.dev 4y ago

Learning from Post-Mortems

dglass
1pts0
www.cnbc.com 4y ago

Bob Chapek and Bob Iger had a falling out – the rift looms over Disney’s future

dglass
2pts1
twitter.com 4y ago

How to piss off other programmers

dglass
5pts4
www.exponentialbackoff.com 4y ago

Free Ideas

dglass
3pts0
www.exponentialbackoff.com 4y ago

On Choosing a Career Path

dglass
1pts0
www.exponentialbackoff.com 4y ago

How to Beat Imposter Feelings

dglass
3pts0
qz.com 4y ago

The US may have a new top secret space weapon. What is it?

dglass
5pts1
www.php.net 6y ago

PHP 8.0.0 Alpha 1 available for testing

dglass
49pts51
zenhomeowner.com 6y ago

Show HN: A project management and CRM tool for homeowners

dglass
5pts2
www.exponentialbackoff.com 6y ago

Run Deno in Docker

dglass
2pts0
medium.com 6y ago

You Need to Find a Work Crew

dglass
1pts0
medium.com 6y ago

Social Debt: The dark side of working from home

dglass
1pts0

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.

  <script setup>
    const items = [1,2,3,4,5,6]
    let runningTotal = 0

    const getRunningTotal = (item) => {
      runningTotal += item
      return runningTotal
    }
  </script>

  <template>
    <ul>
      <li v-for="item in items">
        Item {{item}}; running total {{ getRunningTotal(item) }}
      </li>
    </ul>
  </template>
No need for a computed property. Plus, getRunningTotal can be unit tested, or extracted to another file for reusability.

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.

https://www.tracket.com

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.

Contact info: dave @ tracket . com or https://www.tracket.com/contact

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.

You will never switch databases

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.

On Trucking 4 years ago

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.

[0] https://www.platformscience.com

[1] https://www.platformscience.com/jobs

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.

book: https://www.holloway.com/b/junior-to-senior

newsletter: https://newsletter.beginner.dev/

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.

[0] https://www.holloway.com/b/junior-to-senior

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.

[0] https://www.holloway.com/b/junior-to-senior

[1] https://www.holloway.com/

[2] https://www.holloway.com/g/junior-to-senior/sections/how-to-...

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.

[0] https://www.holloway.com/g/junior-to-senior/sections/how-to-...

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.

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.

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.

Shameless plug, but I’ve written a book about what differentiates a good programmers from great ones. [0]

In my opinion the soft-skills far outweigh a person’s technical skills in terms of importance when it comes to identifying whether is a good programmer and should be promoted to a senior position. Obviously the programmer needs to have strong technical fundamentals, but the essential soft-skills are things like:

* good communication skills (speaking, writing, and also listening)

* Reading and understanding unfamiliar code

* Recovering from mistakes

* Understanding how to add value

* Understanding how to manage risk

* Dealing with conflict in a professional way

* Managing your time efficiently

* So much more

A lot of those things can be learned over time, but historically I’ve seen junior engineers put these things off until a few years into their career when they’re ready to make the jump to a senior role, only to find that they’re lacking in one or more of those necessary soft-skills needed to get the promotion. I’ve always advocated for juniors to start working on these skills as early as possible in their careers, because it will make you a better programmer in the long run.

[0] https://www.holloway.com/b/junior-to-senior

Always cool to see what tools other authors use to write books. I took a different route with my upcoming book[0] on career advice for programmers working towards a promotion to a senior role.

I started out writing it in markdown but ended up moving to a workflow that was mostly Google Docs. My general flow was:

1. High level chapter outline

2. Outline for each individual chapter

3. Write each chapter according to the outline

4. First draft done!

5. Read through each chapter and highlight each sentence according to color code (Green: good, Orange: good but needs to be revised, Red: bad, needs to be rewritten)

6. Work through each chapter and revise/rewrite based on colors.

7. Second draft done!

8. Developmental edits (Get feedback, move chapters or sections around, add missing sections or talking points)

9. Copy edit (This is where I'm at now)

10. Prepare for publication

11. Done!

[0] https://www.holloway.com/b/junior-to-senior

Service classes are a common pattern used in monolithic codebases to isolate related logic from the rest of the system. Everything the author described in the article can absolutely be built in a monolithic codebase sharing the same database, or separate databases if you prefer.

Shameless plug, but I'm working on a job board[0] specifically for entry level developer jobs. I'm hoping to open source the job board code as well so it's taking a little longer but I'm close to making the repo public. I also publish a free weekly Substack newsletter geared toward entry level devs[1] and am close to finishing a book about soft-skills for entry level devs[2].

Why do I do all of this? Because I was also an entry level dev once.

[0]: Not live yet but it'll be at https://jobs.beginner.dev

[1] https://newsletter.beginner.dev/

[2] https://www.holloway.com/b/junior-to-senior