• 0 Posts
  • 9 Comments
Joined 5 months ago
cake
Cake day: January 25th, 2024

help-circle



  • Background: 16 years programming professionally, 20+ including hacking in high school. Currently in a principal engineer role.

    Immediate reactions: you do not have to program in your free time. I ferment veges, I brew kombucha, I garden, I make hot sauce, I hike, I camp, I spend time with my dog, I game, I listen to music, I make music, I work on my house. I absolutely do not fucking program in my free time. I used to love programming, now it’s “what I do”, but I don’t love it.

    That said, you may have to invest some of your free time to grow your skills. But your primary learning should be during your paid hours. If your job isn’t providing growth, that’s an issue with the company. There are better junior positions out there, but it is a guessing game. I do think it’s important to mention that the jump to senior is largely an accumulation of domain knowledge, not necessarily industry knowledge. Climbing the ladder is often a matter of sticking around long enough to get that promotion, then leveraging it into another company.

    I wouldn’t blame you for taking the alternative job - and honestly, the best program managers, the best team leaders, have some experience doing the actual work. I’d say do it if it seems like a better opportunity. You can always circle back if you prefer the individual contributor route.



  • halcyon@slrpnk.nettoBooks@lemmy.mlFiction!
    link
    fedilink
    English
    arrow-up
    0
    ·
    5 months ago

    Robert Evans’ (from the Behind the Bastards/It Could Happen Here podcasts) book After the Revolution is a great future sci fi read.

    Parable of the Sower by Octavia Butler is a tough but good read, if The Road didn’t get to you too much, you’ll probably enjoy this too.

    A Canticle for Lebowitz is another dystopian sci fi future novel I’d recommend if you aren’t put off by older writing styles (1950’s).





  • Alright, I commented a quip/anecdote in a thread below, because I figured this was an easy answer that didn’t need another piling on, but I’m not happy with any of the answers so far.

    OOP is, at its core, representing a data structure as an object.

    For example you may have a Customer, and that customer may have properties such as their id, their name, their revenue.

    So instead of passing those properties as a tuple or list, you can first define that object, and then construct new instances of the object that store each property, that can be passed and accessed as a single variable.

    The magic of OOP really comes in when you get into inheritance. Imagine you have two types of customers, one needs to represent id, name, revenue; the other needs to represent id, name, debt.

    You could add a debt property to your original Customer object and reuse it (probably more practical in this case) but as an example,

    Or, you could define a Customer object with the properties id and name, and then define a CurrentCustomer object inheriting from Customer, which forces you to implement id and name, and then you can extend it to include Revenue. Likewise for the OverdueCustomer object, inherit from Customer, implement the id and name required by the parent, and then add the Debt property.

    That then allows you to write a method that accepts a Customer variable that could work with a CurrentCustomer or OverdueCustomer object, since they’re both inherited from Customer they can be passed as Customer types. And that method then implements logic to determine whether we should forward to standard billing or collections. Since both objects descend from Customer, we know that id and name will always exist, and we can use if/case statements to determine from there.

    Now think about that in terms of what you can force inheritance of. You could create a DatabaseConnection object, which forces the implementation of not only the database_name property, but also the ExecuteQuery method. Each implementation then needs to define how they connect to their own database instance. Now we can create objects that connect to either Snowflake or SQL Server using the same syntax.

    This is generally how APIs are implemented, the parent library tells you what you need to implement to construct objects that will work with their methods, and once you inherit that and construct a version of the object, you can pass that as if it’s native to the original library.


  • Once upon a time, “big data” was datasets large enough that it was impractical to try to store or work with them in a traditional relational database software. Which is where distributed structures came into play with the ability to spread both storage and computation across clusters of machines, using solutions like Hadoop and MongoDB. That seemed to be the direction things were heading 10 - 15 years ago.

    However, with the automated scaling built into modern cloud databases, the line has gotten a bit blurry; Snowflake, Redshift, BigQuery all handle many billions of rows just fine. I probably wouldn’t use the term big data in a professional context these days, but there is a table size after which I write code a bit more carefully.

    I suppose my point is that the term once meant something, but marketing stole it because it sounds cool. I worked in a tech shop in the late aughts where the sales team insisted on calling every rack mounted server a “blade server”, regardless of whether it had modular swappable boards. Because it sounded cool.