Hacker News Reader

Comment by jxm262 | Hacker News Reader

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.

View on HN

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.

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.

I agree that "padding" is necessary. It is called estimation because there is some level of uncertainty. Part of your job as a consultant is ensuring that the client is aware of and comfortable with this level of risk. I bill by the hour, so my risk is mitigated, while my clients know from experience that I tend to deliver on time and rarely have them go over budget (that is where your estimation ability comes in). If you are doing project-based pricing (as others advocate), then I assume a more significant amount of "padding" is called for, to limit your risk.

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.

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.

Prediction only works for what you know. Seems obvious, but people have a way of "forgetting" that. So you estimate within the parameters of what you know about. If what you know changes, then your predictions have to change.

There are various points on the predictability curve. I used to work in an environment that was extremely predictable: projects with well-defined scope that took years to complete and changes were tightly managed. If scope changed, the stakeholders understood the cost to the schedule. An environment like that is perfect for using past time estimates vs. actual time taken to estimate future similar or dissimilar-but-related tasks.

In other environments I worked in, it's more chaotic. Things change frequently, so estimates change frequently. Often you your long term vision is compromised by firefighting, so that vision has to be adjusted constantly. If you have a deadline, then tasks need to shift to meet the deadline.

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?

Curious about that. What kind of "medical" work do you do? I spent a long time developing for Medical Devices and while I shudder at the thought getting back into that specific field, I am thinking of consulting on the periphery where the knowledge of CFR21 & FDA expectations is useful but without getting into full DMR/DHR paperwork.

Software for medical devices. A lot of my clients are very early stage (e.g. prototype development) so the regulatory burden is not as high as during commercialization. That said, one of my current projects is writing an updated SAD (software arch. doc) for a decent size application.

You sound extraordinarily like me. I work in the same field, am writing a SAD for a client right now, and have been thinking of breaking off from my employer to promote myself as that guy you get in for concept development phase and establishing an overall software architecture and development process. That's the bit I enjoy, but the final polishing and commercialisation phase around transfer to manufacture just saps my motivation!

Reply on news.ycombinator.com