Live data from Hacker News

Rules of thumb for a 1x developer

muldoon.cloud

411–420 of 505 posts

Re: Rules of thumb for a 1x developer

#411
post #58

I'm not sure how I should be reading the article so maybe it's going over my head. > Rule 10: When to make a microservice > I would use a microservice when I have a relatively small and simple chunk of code that needs to run every once in a while. Isn't this wrong? There's no reason a microservice should just run once in a while. It also creates a lot of complexity for a simple chunk of code.

Most of this article could be ripped to shreds based on its accuracy. But that isn't the point - he has developed a set of rules and guidance that work for your average developer just slinging code in an enterprise. And while yes, almost everything he says is "wrong" if we push the details... I can see that they are all "close enough" to build a workable framework for your basic 9-5 1x dev.

> almost everything he says is "wrong" if we push the details

Author here. Part of the point was to expose my ignorance and get people to rip it to shreds. So have at it if you want. I've actually learned a good amount so far using this method.

Re: Rules of thumb for a 1x developer

#412
post #403

Earlier quoted context omitted.

> Congratulations, you are now 3-10x developer. Congratulations. You are still getting paid the same. Boosts in productivity need to come with boosts in pay, otherwise the logical thing to do is to scale back your effort to a point where the amount you get done matches the amount you get paid for.

I’ve never heard of a company that will offer to pay you more if you promise to be more productive in the future. What industry are you in? All of my raises and promotions came from results that exceeded expectations.

There is a balance though. The company I work for is stable, but money is always tight. That means raises are few and far between.

Other factors balance that out and make it a reasonable place for me to work, but being aware of the fact that "exceeds expectations" does not lead to more money is important and I'm sure not unique to my situation.

I'm happy to go above and beyond, but I'm also aware that it's unlikely to be rewarded and take that into account in my decisions.

Re: Rules of thumb for a 1x developer

#413

Earlier quoted context omitted.

I can implement streaming architectures using the latest technologies that can handle throughputs of TB per hour. I can handle the architecture, security, infrastructure as code, and monitoring, as well as the development. I can also help with price vs feature analysis. I have demonstrable experience in doing so, with happy references. I can do it much faster and more successfully than a recent college grad. Shouldn'…

I was in agreement with you until you mentioned security. Peer review and avoiding your own bias is essential, you can’t do that alone.

Well, I didn't say I do security alone. The types of companies I work with other have an entire security group. But I can absolutely begin the architecture with proper security principles in mind and I can go through the review process with both peers and groups. I certainly know where to start with security and the security issues inherent with eventing and streaming. Which I guess is the point. I also don't often engineer the entire application from soup to nuts but I guess I technically could.

Re: Rules of thumb for a 1x developer

#414

Earlier quoted context omitted.

So is every professional you pay money to. But you will still recommend some and not others. When times get tight, those guys still make a living.

If you are an independent service worker yeah, I understand, go the extra mile with your customers, it is good for business. But if you are drone #139098123 in generic corporation X, you should not give a fuck on your reputation as long as you are doing your work. If they dump you, you go and get another job, there is a big world out there.

> you should not give a fuck on your reputation as long as you are doing your work

But we're talking about reputation based on the quality/quantity of work you do.

I think there's a difference between taking pride in your work, and breaking your back for your employer. I think the former is what's being advocated for in this thread.

Also, if you feel like you're drone #139098123 in a soul sucking abyss, and can't be bothered to be interested in the activity you spend a majority of your waking hours supposedly doing in this short life, then I encourage you to look for something better. I know all too well that it's easier said than done, but it's better to start while you still have the soul sucking job instead of after they "dump you."

Re: Rules of thumb for a 1x developer

#415

Earlier quoted context omitted.

I can implement streaming architectures using the latest technologies that can handle throughputs of TB per hour. I can handle the architecture, security, infrastructure as code, and monitoring, as well as the development. I can also help with price vs feature analysis. I have demonstrable experience in doing so, with happy references. I can do it much faster and more successfully than a recent college grad. Shouldn'…

How does one get experience architecting stuff when most roles usually require experience?

If you have a role now, start working with the architects to gain experience. Become friends with all of the architects. Learn from them. Then ask your organization to move you to an architectural role. Maybe without any sort of pay increase. The point is to get the verifiable experience on your resume. Then you can move.

Re: Rules of thumb for a 1x developer

#416

> Rule 20: When somebody says Agile, push for Kanban, not Scrum... ...Scrum can easily mean that you’ll get pressured to work extra hours to complete something within that arbitary two-week horizon. This is very true. I've worked for over 12 years in the bay area in different software engineering teams at startups and found that scrum just leads to burnout and developer unhappiness and encourages team members to just…

To be clear: XP and Kanban are different things. XP has prescribed engineering practices, most forcefully that development should be done via pair programming for continuous code review. Kanban prescribes no engineering practices and could be used in lots of non-engineering contexts (e.g., your marketing team could take all of their tasks, put them in a prioritized backlog, then track the progression of those tasks across Todo/Doing/Done/Blocked and that would still be Kanban). Kanban is great for teams in maintenance mode with a steady in/out of smaller tasks in their backlogs, but it's not great for helping your customers get an idea of when they might see a new product or feature.

I do find it odd that people describe Scrum as "leading to burnout" or a "death march", and I'm guessing most people who do either have not worked in waterfall IT projects that preceded widespread Agile or they're part of "Agile" teams that do waterfall development in two-week chunks with daily standups. (Maybe both.)

Scrum practiced well brings the essence of small-town democracy into the workplace. You have to work a late night the day before sprint release? You were in the room when the team agreed to the body of work that would be committed for delivery in this sprint. You just slapped it together until it works? You'll get to accommodate 0-point bugs in a future sprint, and perhaps you can have a conversation in your team's retrospective about why velocity went down that week. (Speaking of: how many other professions get to have a candid conversation with management about what's going well and not going well on a regular basis? Not many, it's a real privilege!) There are certainly deviations from this, but in my experience Scrum teams' problems are generally of their own making, and many of those problems are refined away over time as teams grow and better define their norms.

Re: Rules of thumb for a 1x developer

#417

> That’s all that Agile means to me. This is the most concise, honest summary of "agile" I've ever come across. Well put. The amount of person-hours spent bikeshedding about various sundry "agile" procedural details is absolutely breathtaking. A perpetual, real-life Dilbert punchline taken seriously by armies of *Managers.

Well that's pretty naive. I've worked with some pretty good teams that wouldn't work any other way. I suspect you've only worked at places that abused agile as described here... https://ronjeffries.com/articles/language-of-hatred/

I think the key to those teams is probably that they were pretty good teams. Wouldn't be surprised if they got great results using Three Seashells.

Re: Rules of thumb for a 1x developer

#418

Earlier quoted context omitted.

Don't interview for a manager. pick a growing startup, ask in the interview about developer career paths, and if management is a separate, lateral, or heirarachical stack (correct answers is "lateral track devs can switch into") Get good at your job. Get good at the company. Learn the domain and drink the koolaid. And, when the team grows, and they're looking for managers, nominate yourself to begin transitioning. Yo…

I think you missed my point entirely. I did those things for 10-15 years, and they led nowhere. Either it's one reason or another from a current employer, or none of it counts with prospective employers all because I didn't already have a manager title.

Sorry, I did miss that. It is unfortunate your employers are not supportive of your career ambitions. I've watched many engineers become managers at PlanGrid, so I know it is possible :)

Re: Rules of thumb for a 1x developer

#419

Earlier quoted context omitted.

> the deluge of recruiter spam on LinkedIn hasn't slowed down yet Recruiters spamming you is not a correlative metric for companies hiring you. SV is worse than other locations, but even the midwest company I work for (I'm also over 40) much prefers to hire people straight out of college. They're cheaper, willing to work longer hours, and easily molded into an image the company wants. EDIT: To provide a small anecdot…

Anybody know if it's possible to block Amazon recruiters on Linkedin? If not, I'm going to ask the next one to flag me in their system, if that's possible.

Why would you burn bridges in such a way?

Re: Rules of thumb for a 1x developer

#420
post #389

Earlier quoted context omitted.

To be completely frank, I'm seeing less and less reason to use traditional sql databases. MongoDB offers the ability to make sql queries and even has Acid transactions. Everything SQL can do, it does without slowing down when dealing with big data. The only thing it doesn't offer an efficient solution for is something SQL can't do either, and that's advanced search engine capabilities like Elasticsearch provides. Som…

Riiiiiiightttttttt, because having well defined data is not useful at all.

Also, MongoDB queries for related records can be painful. This takes a while to realize, but definitely shows itself when you are working with more complex data.
Post reply on HN