You are viewing a single comment's thread from:

RE: The life of a steemit developer: Overview of 14 days after quitting my job

in #life • 8 years ago

Good post! I thoroughly enjoyed reading it.

The hardest I have ever worked was when I was working for myself. I tended to go the extra mile (often unnecessarily) because I wanted my projects to clearly reflect my ambitions and vision of what they could become (long story short - In the end I burnt myself out badly).

After that I fully understood the value of having a team and joined a company that I felt I would work well with. It's nice to have access to real world tested skills and experience i.e. an actual designer or accountant, also working with a team allows me to forget about admin and focus on my specialty and what I love most : programming

I would love to know more about your planning system / approach - it would be great if you could do a post on it. I have no issues planning dev for single projects but when there are multiple projects overlapping I struggle. Currently I am re-writing an ancient framework which breaks down into 6 large systems which function seperatley but have inter-linked dependencies and I am having a rough time with planning and getting it onto some sort of time-line.

Somehow I need to get thier individual modules onto a stacked timeline since a single module in one system requires another module in a seperate system to exist before it can be written - so all 6 systems need to built asynchronously at the same time. I was going to write a custom planning system but I am short on time and don't have a clear vision on how to structure it so instead I went with a run of the mill ticket system which keeps track of what needs to be done but still doesn't help with time planning.

Anyway sorry about the essay,

Thanks again for the great read.
- Kurt
8 years ago in #life by
$0.00
    1 vote
    Reply 3
    Sort:  
  • Trending
    • [-]
     8 years ago (edited) 

    Kurt,

    My recommendations are:

    1. Get an enormous whiteboard.
    2. Draw the system as it exists today.
    3. Pool the shared pieces, which we will now refer to as the core. You can put this in a circle in the center. The stuff that goes in the core is anything that is used by more than one of the separate pieces.
    4. Model the core as a list of inputs and outputs
    5. Separate the separate pieces (these should be their own app / system / whatever) (Bear in mind that there may be more or less than six of them)
    6. Model each separate piece as a list of inputs and outputs.

    So, that should give you a pretty clear vision of the structure. However, time planning is another matter altogether, and something that I am not very good with myself. You may want to try something like this, however:

    1. Figure out how long it will take approximately to write the core. Now double that time. That's how long you should have budgeted to work on the core.
    2. Do the same thing-- including the doubling for each of the other peices.
    3. If possible, write it so that non-core pieces function independently of each other. This way you can do those sequentially.
    [-]
     8 years ago  

    Thanks for the feedback. My main issues are around time planning, as stated I don't have any issue with specs. My enitre office is a white board lol (I got whiteboard paint and painted the walls) , I like your idea of pooling them and think I am going to give that a try - atleast then it should give me a clear indication of when each feature needs to be written, I can then use the estimated time per feature to generate a timeline.

    $0.00
      Reply
      [-]
       8 years ago  

      You got it!

      That's the way to go, IMHO. Once you've got that central core built, adding the features onto it shouldn't be too tough. And don't forget to multiply by two!

      $0.00
        Reply