Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Beware of Developers Who Do Negative Work

blog.professorbeekums.com

Post reply on HN
Print view View original

241–250 of 271 posts

Re: Beware of Developers Who Do Negative Work

#241

Post by chrisabrams »

ThePhysicist wrote: post #121

Considering that the author writes on his resume that he lead several teams, it startles me a bit to see how easily he puts all the blame on the developer and none on the other team members (including him) and the management. The way I see it, as a senior developer or team lead it is your job to make sure that your junior level programmers are doing good work, and if they don't, you either help them to improve or (if…

> ask yourself how you can build a process that makes it really hard for individual programmers to do bad work

That is a very constructive way at looking at things; I think I'll try this out with my team :)

Re: Beware of Developers Who Do Negative Work

#242

Post by cookiecaper »

jdbernard wrote: post #236
cookiecaper wrote: post #227

Earlier quoted context omitted.

Be careful with this. It's usually a sign of a political double-talker. The manager hasn't forgotten who he works for, even if he wishes you would.

Well, it depends. I've been in healthy situations where this was true. One company in particular where this was mostly true from the very top down. Of course, yes, there are plenty of situations where it is just double-talk.

The manager isn't a good politician if you don't believe his bullshit.

If the manager himself is a founder, former programmer, or otherwise both intimately familiar with and committed to the process that actually produces the outcome, he may understand the importance of the work and really be working to ensure his team has what it needs so they can do a good job for the company. He's still working for the company, but he appreciates and understands engineering, and since you're working together for common goals from a common understanding, your interests are aligned.

You can almost always expect people to consider their field of expertise the nexus of the company's lifeblood, the critical component that everything will die without. Everything else will be considered tertiary. In the case of most managers, their expertise is schmoozing, and that's going to be their primary focus. To the extent that good engineering jeopardizes schmoozing, you can and should expect the manager to strongly prefer schmoozes.

Re: Beware of Developers Who Do Negative Work

#243

Post by Terr_ »

indexerror wrote: post #74
renolc wrote: post #44

Earlier quoted context omitted.

This is definitely true on both ends. At a previous company, the tech influencers believed in the archaic "do everything in the database." While we were technically using the .Net stack, we weren't allowed to do any actual business logic in C#. Instead it had to all be done in MS-SQL procedures (or at least at much as possible with very little CLR glue). Similarly at my current company, we had a product were the init…

Can you explain why you feel that "do everything in the database" is archaic? A lot of logic (especially authentication logic) can be put in the database only. Not to mention that I won't trust anything that only has application level security, and nothing at database level to check/limit it.

I'm fine with it as long as:

1. Everybody recognizes that "The Database" has now become its own unique product, which just happens to provide remote service-calls to other products over an SQL channel

2. I'm not the one responsible for managing the multi-tenant clusterfuck it will become

Re: Beware of Developers Who Do Negative Work

#244

Post by larrik »

jdbernard wrote: post #234
user5994461 wrote: post #224

Earlier quoted context omitted.

Most stuff isn't developing. Designing, planning, architecturing, reviewing, developing, testing, delivering, maintaining, presenting... That's all a developer's jobs. I don't think that they should be strictly limited to "that guy who's got a special job title" (architect, managers, lead, whatever).

The way I interpreted larrik 's comment, he meant things like interfacing with other layers in the company, interfacing with other managers about the team's capacity for support, etc. Most of the things you mention I would include in "development". What you seem to call development I would specifically call implementation. Although, it can be beneficial to have different people for a lot of the things you mention, es…

Your interpretation is indeed what I was aiming for.

Re: Beware of Developers Who Do Negative Work

#245

Post by jakub_g »

phereford wrote: post #185
ThePhysicist wrote: post #121

Considering that the author writes on his resume that he lead several teams, it startles me a bit to see how easily he puts all the blame on the developer and none on the other team members (including him) and the management. The way I see it, as a senior developer or team lead it is your job to make sure that your junior level programmers are doing good work, and if they don't, you either help them to improve or (if…

I have dealt with the "negative work" conundrum myself and just wanted to give some insight from my point of view on your comment. 1) It isn't always junior level programmers causing the negative work. When it is a junior level programmer, you are 100% correct that part of the blame (or MOST of the blame) falls on the lead/senior programmer. The lead/senior failed the junior without the appropriate structure, code re…

Bonus points if the senior/lead in scenario 2 really, really likes coding, and adds technical debt, bugs and ugly code at a rate faster than the other members can catch up with.

Re: Beware of Developers Who Do Negative Work

#246

Post by jakub_g »

alkonaut wrote: post #92
woah wrote: post #79

Earlier quoted context omitted.

Functional programming does have some useful syntax and principles that can make code easier to reason about. But a much bigger red flag is if a developer is so fixated on a certain programming philosophy or methodology that they don't pay attention to writing simple, good code.

> that they don't pay attention to writing simple, good code. Amen. If you have a complex problem to solve, and the style is between obfuscated FP and complex OO, the choice is already a bad one. If the code can't be written very clearly, probably the problem is posed wrong, or shouldn't be solved because the maintenance costs will be too high anyway. The negative contribution developers I find are those that don't c…

> The negative contribution developers I find are those that don't challenge the formulation of the problem.

Couldn't agree more. Furthermore, sometimes the best code is no code at all. If the code has 0 lines, it will not contain bugs, and will not take time for bug fixing and maintenance.

Re: Beware of Developers Who Do Negative Work

#247

Post by walrus1066 »

matt_wulfeck wrote: post #232
walrus1066 wrote: post #76

Earlier quoted context omitted.

Danger with this is people recommend based on friendship & personal gain as much as competence. You can end up with mini guilds of ~5 people, who know each other well, and help each other with their career by recommending each other as they migrate from company to company. Seen this happen twice now. At my current company, someone joined the devops/infrastructure team, then brought 4 over from his network at his prev…

I've seen it happen as well. If you look at each person individually you may have issues, but does the team function? Do they get their work done and stay out of your way? For all I care they can have a dog on their payroll as long as their team does what it's supposed to do and stays out of my way.

The team sort-of functions. But they're stuck in a form of groupthink, where they seem to prefer building their own tools/scripts, our server monitoring is poor/non-existent (only application logs), they are very reluctant to move to AWS, security obsessed to the point of manually setting routes and firewalls manually, very poor automation overall etc etc

But because they dominate our devops/infra, it's very hard to penetrate the groupthink, our CTO is thankfully getting involved.

Re: Beware of Developers Who Do Negative Work

#248

Post by walrus1066 »

MereInterest wrote: post #145
walrus1066 wrote: post #80

Earlier quoted context omitted.

I feel your pain. Scientists & data scientists are notorious for spaghetti code. Refactoring scientists code was how I got into software engineering. I used to be a scientist, and I found restructuring/modularizing the analysis code more fulfilling than the actual analysis.

As someone who is currently in that exact situation, and is considering switching away from science, how did the actual switch from science to software go?

For me, the key things were :

- get really proficient in a language, for me it was python, it is a solid, flexible, minimal boilerplate, can use it already for science applications (amazing libraries for it, like pandas, scipy etc)

- understand databases, and how to interact with them

- start testing (unit, integration and acceptance), this is super important, and key difference with scientist programming. When doing a take home test for a job interview, always include tests, even if you get the solution wrong, they will give you massive points for having tests.

- start applying! You'll fail a lot, but you gain experience with each test and interview you do.

Re: Beware of Developers Who Do Negative Work

#249

Post by walrus1066 »

bad_user wrote: post #150
walrus1066 wrote: post #105

Earlier quoted context omitted.

I find a lot of CS education is not applicable to most SE roles, as they operate at a higher level of abstraction. I've never had to implement a binary tree, if I did, I would be reinventing the wheel. A lot of the necessary skills are hard, if not impossible, to teach in higher education. Mainly because there, you tend to be given an exact, unambiguous specification. Whereas in the commercial world, I've never seen…

> Implementing the code is the easy bit :) For web forms that replace an Excel spreadsheet, the kind that usually gets passed around over email or in a Dropbox, yes, the business requirements are usually the ones that are problematic, as you are expected to grok a lot of domain specific details in only a couple of days. But then again IMO, your experience is biased by the problems you've been working on. > I've never…

I think the best (though not prefect) method to test new devs is with a take-home exercise, no time limit, that is representative of your domain. The key things I look for are:

- did they understand the requirements? If not, did they ask for clarification?

- did they choose appropriate abstractions?

- is the code easy to read? Is it overengineered? Are they trying to show off by overcomplicating things, or optimising prematurely?

- the simpler the solution, the better

- are the tests good, readable, not too brittle

I then ask them how would they extend the code to fit new/changed requirements, they don't necessarily need to write any extra code in my presence, whatever they're most comfortable with.

Re: Beware of Developers Who Do Negative Work

#250

Post by jholman »

yoz-y wrote: post #210
djrobstep wrote: post #103

Earlier quoted context omitted.

I just tried to commit a stored procedure to git and it seemed to work. I then asked a colleague to review it. This also worked.

Ok. I did not know that. As I said this is what I have gathered from what I have read around as a common complaint. Out of curiosity, what is the testing-deployment cycle of stored procedures in source control? How do you assure yourself that the database uses a procedure coming from a specific commit?

How do you assure yourself that your non-database code uses code coming from a specific commit?

In general, you have a deployment procedure that overwrites all the old code with all-new code, and from there on out you trust, right? Why not use the same approach?

Post reply on HN