3 ms·

Yeah, everyone is telling me to rely on personal/professional network. The problem is that most of them are fellow "enterprise" type programmers without any ac

by jxm262 11y ago

Yeah, everyone is telling me to rely on personal/professional network. The problem is that most of them are fellow "enterprise" type programmers without any actual work to give (ie. not hiring managers). Also.. the big issue I have now is finding evening and weekend/part-time jobs. It seems pretty easy to find a decent contract at a company if I transition, to say, full-time for 6 months or whatever they offer. When you say you were top X% , was that in a specific tech stack or niche industry? I'm really good at certain tech stacks (JavaScript world - Node+React+AWS, or Java/Scala world - Spring, Play, etc..). How do you actually find work that will help you "level" up, per se. And more importantly, show others that you're an expert in the field? I can do _awesome_ work for some people but it might not be broadcasted to the rest of the world if it's just known internally.

kohanz 11y ago
Starting on evening and weekends is tough. I know one of my clients is alright with that, because our relationship is more casual, but I don't think the rest would be comfortable with me operating so casually for their business (they want me to be available for calls, e-mails, etc. during the business day). The thing is, the kind of service I provide is not just "let me go away and program something for you", it walks them through the process from conception all the way to deployment. I'm in a niche field (medical), but the people I'm dealing with are generally non-software folk. To them, I am a product guy, project manager, developer, architect, etc. all in one. When I say top X%, I don't mean in a pure technical sense. I mean in the sense of, from management's perspective, if they had a project that they valued highly and knew they wanted to deliver on, who would they pick as the technical lead for that project. Which technical person would they put in front of the customer? Who would they want to be alongside them during the hiring process to find more technical folk? Those are the ways in which I've found I've been valued. I feel like I am a good programmer (who doesn't?), but I'm not the best programmer in the room. It's a more rounded skill-set and a willingness to do valuable non-programming things. A perfect example is a guy I used to work with - excellent programmer and very well-versed in computer science (whereas my background is engineering). In terms of speaking about best practices, patterns, development philosophies, etc. - he was very good, better than me (truthfully some of that stuff bores me). However, in terms of getting a project done in a high quality way, with predictability (estimation, scheduling, etc.), those are the things he didn't really care for, but I paid attention to. He's a great programmer and a good asset to any organization with a team, but I don't think he's do well on his own. Make sure you are confident in your estimation skills before going it alone.
- UK-AL 11y ago
  I don't think I've worked with an organisation, or a PM that could actually estimate well in software without using padding. I think the prevalence of story points, and probability based estimates(markov), proves that hard deadline estimates just don't work. I don't trust anyone who says they can actually do it on large projects, because they're either padding or lying.
  - HeyLaughingBoy 11y ago
    Padding is not a bad thing if done right. The group I worked most recently with had an estimation target of +/- 20% and we were usually much better than that. It takes a lot of discipline and detailed time recording to get to the point of being able to accurately estimate a task. Padding becomes useful when you know that you always estimate 15% low. Then after you finish your "real" estimate, add 15% and you will be close to the actual value. I like to think of the estimation process as being analogous to Feedback Control theory. It requires good input data and negative feedback to stay on track.
    - UK-AL 11y ago
      How you can predict the future estimates based on recording now? What makes software estimation so difficult is that it's like maze. How long will take you to complete a maze? You don't know what's coming up in a maze, and you cant give an exact estimate. And trying to work out details to work out what is coming up, takes almost as long actually programming it. This is why I promote the idea that variation should be inbuilt into methodology. Remove the assumption software can be accurately estimated, build methodology around the fact it's hard to predict. I use guestimates of 'effort', but I don't hold people to it.
      - kohanz 11y ago
        exact estimate I think you've imposed an unachievable standard here. This is why I promote the idea that variation should be inbuilt into methodology This may well work within an agile team deep in an organization, because the business of turning "effort" into costs is abstracted from you. At the end of the day, if you're a consultant with a client, they are going to ask you up front for a rough cost estimate. If you can't estimate the time you'll need with any level of confidence, how do you propose to land their business?

by jxm262 11y ago

kohanz 11y ago

Starting on evening and weekends is tough. I know one of my clients is alright with that, because our relationship is more casual, but I don't think the rest would be comfortable with me operating so casually for their business (they want me to be available for calls, e-mails, etc. during the business day). The thing is, the kind of service I provide is not just "let me go away and program something for you", it walks them through the process from conception all the way to deployment. I'm in a niche field (medical), but the people I'm dealing with are generally non-software folk. To them, I am a product guy, project manager, developer, architect, etc. all in one. When I say top X%, I don't mean in a pure technical sense. I mean in the sense of, from management's perspective, if they had a project that they valued highly and knew they wanted to deliver on, who would they pick as the technical lead for that project. Which technical person would they put in front of the customer? Who would they want to be alongside them during the hiring process to find more technical folk? Those are the ways in which I've found I've been valued. I feel like I am a good programmer (who doesn't?), but I'm not the best programmer in the room. It's a more rounded skill-set and a willingness to do valuable non-programming things. A perfect example is a guy I used to work with - excellent programmer and very well-versed in computer science (whereas my background is engineering). In terms of speaking about best practices, patterns, development philosophies, etc. - he was very good, better than me (truthfully some of that stuff bores me). However, in terms of getting a project done in a high quality way, with predictability (estimation, scheduling, etc.), those are the things he didn't really care for, but I paid attention to. He's a great programmer and a good asset to any organization with a team, but I don't think he's do well on his own. Make sure you are confident in your estimation skills before going it alone.

UK-AL 11y ago
I don't think I've worked with an organisation, or a PM that could actually estimate well in software without using padding. I think the prevalence of story points, and probability based estimates(markov), proves that hard deadline estimates just don't work. I don't trust anyone who says they can actually do it on large projects, because they're either padding or lying.
- HeyLaughingBoy 11y ago
  Padding is not a bad thing if done right. The group I worked most recently with had an estimation target of +/- 20% and we were usually much better than that. It takes a lot of discipline and detailed time recording to get to the point of being able to accurately estimate a task. Padding becomes useful when you know that you always estimate 15% low. Then after you finish your "real" estimate, add 15% and you will be close to the actual value. I like to think of the estimation process as being analogous to Feedback Control theory. It requires good input data and negative feedback to stay on track.
  - UK-AL 11y ago
    How you can predict the future estimates based on recording now? What makes software estimation so difficult is that it's like maze. How long will take you to complete a maze? You don't know what's coming up in a maze, and you cant give an exact estimate. And trying to work out details to work out what is coming up, takes almost as long actually programming it. This is why I promote the idea that variation should be inbuilt into methodology. Remove the assumption software can be accurately estimated, build methodology around the fact it's hard to predict. I use guestimates of 'effort', but I don't hold people to it.
    - kohanz 11y ago
      exact estimate I think you've imposed an unachievable standard here. This is why I promote the idea that variation should be inbuilt into methodology This may well work within an agile team deep in an organization, because the business of turning "effort" into costs is abstracted from you. At the end of the day, if you're a consultant with a client, they are going to ask you up front for a rough cost estimate. If you can't estimate the time you'll need with any level of confidence, how do you propose to land their business?