• 0 Posts
  • 31 Comments
Joined 3 years ago
cake
Cake day: July 6th, 2021

help-circle





  • One you don’t wanna join ;) (Google). I’m still on the free tier of what’s now Workspace and intent to move, but I’m dreading the work that comes with it.

    A year or so ago Google almost killed the free tier (look up gsuite legacy if you want to know more). Back then I prepared to move away and settled on Zoho as my replacement, but in the end Google responded to the community’s backlash and kept the free tier free for personal use (although there are some other restrictions put in place, so eventually a move is inevitable). Zoho might also give you the features you want.





  • jochem@lemmy.mltoLemmy@lemmy.mlSelfhosting single person instance?
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    1
    ·
    1 year ago

    I would not recommend running your own email server. Major email providers like gmail only accept email from servers that have all kinds of measures in place to make them as trustworthy as possible. That’s hard and probably not possible on a home internet connection.

    Filtering incoming spam is also a pain in the ass.

    It’s nice as an exercise to learn how email works, but I would not rely on it.


  • Oh, it should absolutely be the team’s decision and you’re also totally right that Kanban requires a more mature team. People indeed need to be able to recognise and ask for help when they’re stuck (which means being vulnerable, but also simply being able to formulate the right questions). People also need to be able to give feedback to their team members when they feel or see that someone is struggling or not delivering enough.

    To facilitate I always have some form of retrospective in my teams, even when doing Kanban. Sometimes only once every other month, sometimes every two weeks. Highly depends on the maturity of the team and customer.


  • I work in a company where we say that everyone is an expert (and to a very large extent this is really true). We create teams of experts, including more business savvy people. Everyone respects each others expertise and makes sure they can apply it as best as possible. We don’t infringe upon each other’s expertise. We might ask another expert about the why or the how, but we should not assume we know better. Obviously this happens sometimes, but then we remind each other that we’re all experts and that an engineer wouldn’t like to be told by marketing how to do their job either.

    I think this fits nicely with ‘stay in your lane’ and actually makes it easy to remind people to do so. It’s in the core values of the company that people excel in their lane and cooperate with people in other lanes.


  • I would even argue that points, stories and sprints are not things you need. If you go kanban, you don’t need sprints. You still need to be producing and you probably want to get a feel for complexity so you can prioritize, but that can be done without points.

    Stories are also very scrum specific and you can turn them into whatever format you want. I usually still call them stories, but they’re basically just a little card that describes the context (why do want something) and the deliverables (what will be implemented to meet that want).


  • This is literally the critique on waterfall (project goes and makes what they believe the customer want, comes back months or years later, turns out they made the wrong thing and wasted so much time) and what agile aims to solve (have regular check in moments to see if the project is still on the right track and adjust when needed).

    In my experience it helps to define a roadmap and stick with that direction. Figure out the details when you start working on a roadmap item. Adjust the roadmap every 6 months or so, only deviate earlier when the situation calls for it. This requires sometimes being able to say ‘no’ to your customer and them accepting it.



  • Markdown is notoriously understandized, so there are lots of unofficial extensions. This is a major downside of markdown, as you cannot trust a renderer to properly show the formatting beyond the basics.

    It’s still really nice, because of two great features:

    • it’s super easy to learn. Just look at a few examples and off you go.
    • even when it’s not rendered, it’s still easy to read (which I think contributes to making it easy to learn).

  • If I would guess, then it has to do with making long lines fit in a window without requiring horizontal scrolling.

    Markdown is used a lot in the context of software development. Software code is usually accompanied by a readme, detailing what it does, how to setup your environment for development, how to contribute, etc.

    The defacto standard is to write this in markdown. Since it’s written in a software development program (an IDE), you don’t have text wrapping, meaning lines continue when they don’t fit in the window. This is because otherwise the code becomes unreadable. Most code can also be kept to fairly short lines, normally not requiring any horizontal scrolling. However, a long sentence in a readme will easily become much longer than a line of code. So being able to break a line anywhere without having an actual line break in your rendered output is super useful for that.

    This is btw how html also behaves. Markdown gets rendered to html.




  • I started a little over half a year ago with Go, coming from Python like the author. I definitely enjoy working in a strongly typed language and Go is usually quite fun to work with. This week I’m actually implementing a concurrency pattern for a ‘real’ problem, so eager to see how that works irl. I’ve yet to come across something where generics really make sense, but definitely curious to explore that with a real case as well.