81–90 of 212 posts
Earlier quoted context omitted.
Whenever I spend a week without progress I feel like dying. In college I was used to be able to churn immense amount of code. Even if most of it was useless, I'm not well adjusted for long productive-less periods. How did your manager react to these times ? no remarks ? nagging ? trusting ?
Then grow up? Producing huge amounts of useless code is not good for you or anyone else???
Anyone else feel sad when you remove a bunch of code? All those man-hours it took to write that code, and now I'm deleting it all. I believe it's called sunk cost fallacy. I often wish I had a time machine so that I could go back in time and say, hey, this will all be deleted a year from now, go with the other solution instead.
My current task is to implement a feature and I wrote about 50 lines during the last 2-3 weeks. I'm not slacking off, just examining the codebase and planning. I did collect about ~25-50 lines of notes per day though, so it's not like I'm keeping everything in my head. To be fair, the codebase is new to me, so I don't expect to keep this tempo for very long. If I had been pressured to start writing code immediately i…
I once opened up a government code base (in C) that lead with this: "void * * * * x;". It took a while to learn that code. Taking time is fine and good managers will support you, so long as you have something to explain what your time is spent on.
Earlier quoted context omitted.
Progress is measured in more things than code written. Define progress using the right metric, i.e. stuff learned, and the feeling of progress and your motivation can be preserved. For me, it is really a top down approach. I can work on goals that take years to accomplish. But the key is to break them down into smaller and smaller bits until you have work items that show progress on a small enough scale to be easily…
Good point. I do agree with you vastly. But in my few work experience it was never discussed nor shown. Which led .. well lack of leadership. And ultimately deep anxiety. Do most jobs have a team chat to talk about it before going into actual work ?
At their most objective best, everyone on a given development team can gain some insight into the work of others, and how hard it might be.
These session can also be a great way to share knowledge, as developers with different levels of experience and specialisations collectively examine high level goals.
In that, you all have a fair opportunity to either share opinions on the best way to achieve a task, or just merely learn something from someone else about tools or techniques you're unfamiliar with.
And for insightful managers, it's also a great opportunity to communicate high level aims and objective, and occasionally, also break those objectives down, transparently, and explore them.
At worse, estimation sessions can be used as a tool to bully dissenting or inquisitive coders.
Even in it's least positive guise, collective estimation sessions are still valuable. At the very least, you have the opportunity to agree, as a group, on what is, and what isn't going to take 10 or 1000 odd SLOC. You'll also have a better idea (if only slightly better in some cases), of how long that n SLOC will take to write.
Earlier quoted context omitted.
Some of my favourite days on the job is when you remove lines of code. Does that metric go against LOC/written?
Reminds me of https://www.folklore.org/StoryView.py?story=Negative_2000_Li... I once had a senior manager who insisted that developers made at least one commit a day (an internal GitHub like tool gamified this: number of lines committed since last month / top committers in the team etc), and those that didn't, had to up their game . It was frustrating to say the least as this was not the only metric . There were a ha…
Earlier quoted context omitted.
Some of my favourite days on the job is when you remove lines of code. Does that metric go against LOC/written?
Reminds me of https://www.folklore.org/StoryView.py?story=Negative_2000_Li... I once had a senior manager who insisted that developers made at least one commit a day (an internal GitHub like tool gamified this: number of lines committed since last month / top committers in the team etc), and those that didn't, had to up their game . It was frustrating to say the least as this was not the only metric . There were a ha…
Earlier quoted context omitted.
Good point. I do agree with you vastly. But in my few work experience it was never discussed nor shown. Which led .. well lack of leadership. And ultimately deep anxiety. Do most jobs have a team chat to talk about it before going into actual work ?
Yes. In 'Agile' development parlance, you would have an estimation session, where the group will look at the units of work to be assigned, and determine how easy or hard they might turn out to be. At their most objective best, everyone on a given development team can gain some insight into the work of others, and how hard it might be. These session can also be a great way to share knowledge, as developers with differ…
So what's this obsession about it? Is it managers who can't or don't want to properly evaluate the performance of the people they're managing?
Earlier quoted context omitted.
Everytime I read posts like this is like if people are arguing about the tiny details of the small picture, and it makes me sad. Expecially because the big picture is easily stated: Write the least amount of clean code while providing value. (PS: code is liability)
Code is both asset and liability; the asset is the feature set, while the liability has an interest payment in the form of maintenance. The way you put it, you're optimizing for only one side of the books. The fact is that the value in a company is not in minimal clean code; it's in a recurring revenue stream, and ideally profits. Provide the most value with code which has low interest payments. Everything else being…
I think the spirit of the comment you replied to was closer to the "clear and concise" methodology rather than the "as short as is humanly possible" methodology.