|
I once had a standup meeting that lasted over an hour. At 60 minutes on the button I sat down in protest. Nobody said anything. It was rare for things to run over 20 minutes with that group though.
|
#
¿
Feb 3, 2016 02:23
|
|
|
|
| # ¿ Apr 27, 2024 11:50 |
|
|
Virigoth posted:Why the hell didn't you leave? I leave / disconnect when the 15 minute meeting time expires. It would have been topographically awkward, as the meeting was taking place directly outside my non-soundproof door.
|
|
#
¿
Feb 3, 2016 03:10
|
|
|
54.5% Javascript on the backend. Edit: AngularJS and Javascript are only 16% correlated Bongo Bill fucked around with this message at 15:59 on Mar 17, 2016 |
|
#
¿
Mar 17, 2016 15:56
|
|
|
Backend developers are paid more than full-stack ones. Reminds me of.
|
|
#
¿
Mar 17, 2016 16:06
|
|
|
If we want, we'll be able to control for the influence of Satan's own programming language on these statistics when they release the full set. Could title the report "PHP Considered Harmful"
|
|
#
¿
Mar 17, 2016 16:30
|
|
|
Sprint points need to be estimated in good faith, and tying compensation to them introduces an incentive to estimate strategically instead, by e.g. chronic padding. It also means that stories that were underestimated can hurt people unfairly. It's not as bad as lines of code as a proxy for productivity, but it's still not a good one. If you want to identify the most productive programmers on a team, and you're convinced you can do so using numbers alone, you need to find metrics that are difficult to manipulate by means other than actually being productive. As a corollary, you need to have an actionable definition of "productive."
|
|
#
¿
Apr 13, 2016 02:19
|
|
|
Correct pair programming can be understood as "inline review," but it's clear that this comparison only extends as far as informal code reviews, not the formal kind.
|
|
#
¿
Apr 18, 2016 04:01
|
|
|
I mean, we can't just not paint the bike shed.
|
|
#
¿
May 27, 2016 00:57
|
|
|
If you can't think, you can't work. If you can't work, then your job is to recover. The best and fastest way to recover is to stay home and rest.
|
|
#
¿
Aug 4, 2016 21:29
|
|
|
Practice saying "Make a new story for it."
|
|
#
¿
Aug 17, 2016 18:24
|
|
|
The way I like to think of it is: it's axiomatically impossible for the client to get everything they want, and "finished sooner" and "costs less" are things they can want. Establish priorities, with hard business requirements including budgets and deadlines represented as higher priorities.
|
|
#
¿
Oct 12, 2016 17:19
|
|
|
Programming is hard.
|
|
#
¿
Dec 19, 2016 19:52
|
|
|
Every bug happens because a previous story was done wrong. If this happened because it was accepted when it should not have been, then the effort spent on "fixing" it is actually additional effort correctly implementing a rejected story. If it's like that, there's a case to be made that the bug should not be estimated, because the ensuing reduction in velocity is actually accurate - it really did take that amount of time to do it right, and consistently measuring it that way will account for the friction introduced by inevitable human errors. This carries the caveat that it takes a very disciplined organization to process that information effectively; it can exacerbate the consequences of existing bad incentive structures, to say nothing of the complications introduced by prioritization. On the other hand, if the bug is something that was not touched on in the original story, then it's better thought of as an expansion of the scope of that story. That means it merits re-estimation, and the difference between the original estimate and the new one might as well be applied to the bug itself. Most teams are probably better off estimating bugs. I mean, ultimately, like everything else, it comes down to "Why is this being measured?" Bongo Bill fucked around with this message at 04:21 on Jan 5, 2017 |
|
#
¿
Jan 5, 2017 04:17
|
|
|
Ghost of Reagan Past posted:"Who the gently caress wrote this poo poo?" git-blame-someone-else
|
|
#
¿
Jan 12, 2017 05:31
|
|
|
Pair program for an hour on a small toy problem or a small, non-sensitive story from an actual project (ideally one that you are pretty sure you already know how to implement). Set the development environment up completely beforehand. Work on it the way you'd actually work. Let them drive most of the time, ask leading questions if they seem stuck, and encourage them to vocalize their thought process and ask questions. Don't expect to finish it during that time, because they'll be nervous and unfamiliar, but do make sure it's something that could reasonably be finished in that time by a comfortable and confident person already familiar with the codebase and domain. No trick questions. At the end, the most important question is, "Would I want to work with this person every day?"
|
|
#
¿
Feb 22, 2017 20:44
|
|
|
Strategically, how would one start a programmers' union in the US?
|
|
#
¿
Mar 24, 2017 04:00
|
|
|
Truthiness is a blight.
|
|
#
¿
Apr 3, 2017 20:54
|
|
|
Programming is only possible because we proactively accommodate human fallibility. The statement is only sarcastically a reflection of actual feelings of self-worth. It's important to acknowledge errors without ego.
|
|
#
¿
Apr 5, 2017 01:31
|
|
|
Points eventually come to represent something real as the project continues and the team stabilizes. It's very important, however, that management be dissuaded by any means possible, for as long as possible, from reaching the incorrect conclusion that there can exist a mapping from points to time. That way lies Taylorism, perdition, and total project collapse. The reason managers, both middle and upper, are subject to this temptation is because their jobs are very closely tied to calendars, and they experience anxiety when they do not know when something is going to happen, like a baby who feels distressed and abandoned when their parent's face is hidden for a few seconds. I think what's harmful is the notion of sprints. By all means have a weekly or biweekly rhythm, and measure the team's velocity across no smaller unit of time than that, but don't formally plan ahead. You'll work on whatever's the highest priority among the things that are ready to be worked on (ideally visualize priority with a queue so it becomes clear that making something the top priority means making everything else lower-priority). Points must never become a commitment, only a retrospective measurement. Prevent the manager from being able to say "How can we increase velocity?" by instead giving them the opportunity to say "Why was velocity low?" - and then one of the roles of a PM is to be the person the manager comes to with that question, and to always have an answer for it. As often as possible, that answer should be one that gives the manager something to do other than micromanage the devs. That's the ideal, anyway.
|
|
#
¿
Apr 20, 2017 07:30
|
|
|
The term is also sometimes used to describe the type of syntax used in some testing frameworks' DSLs, where they've gotten function names and signatures that mimic that style of writing requirements.
|
|
#
¿
Apr 28, 2017 18:01
|
|
|
Complete silence means that you solved their problem so well that they don't even remember there was ever a problem.
|
|
#
¿
May 24, 2017 21:36
|
|
|
We can't just not paint the bikeshed.
|
|
#
¿
Jun 17, 2017 03:07
|
|
|
My Rhythmic Crotch posted:- I have a pile of tickets in my backlog that have so much political baggage that I cannot close them, delete them, or work on them. They're in limbo. I'm sure this happens else where but I find it really annoying. Have you got a "blocked" tag or something that you can apply to them?
|
|
#
¿
Jun 23, 2017 05:59
|
|
|
Pair programming and test-driven development. Alice writes a valid and failing unit test. Bob changes the implementation to make it pass. In some versions of this exercise, Alice writes the next test, whereas in some versions, Bob does. Keep going until all the requirements have tests demonstrating they've been met. This is the only context in which "writing tests for somebody else's code" doesn't make me wary of other problems.
|
|
#
¿
Jun 27, 2017 07:03
|
|
|
PHP type comparison tables
|
|
#
¿
Jun 30, 2017 01:56
|
|
|
I find Rails tends to encourage a monolithic architecture, which makes for an app that's a motherfucker to break apart when it becomes complex, which you will eventually need to if it keeps growing. Its relatively poor performance also means that you'll sooner reach the threshold where microservices start to look really appealing. Slow monoliths are a perfect fit for prototypes, however, and getting something easy to understand up and running very quickly is what Rails excels at for many other reasons as well.
|
|
#
¿
Jun 30, 2017 02:55
|
|
|
Alphabetical properties is fine as there often isn't a finer logical grouping to use, and if there is, there might be a good case for breaking it up. Alphabetical parameters is the worst thing I've heard all day.
|
|
#
¿
Jul 6, 2017 21:02
|
|
|
Is the Dell one the "developer edition" model that comes with Linux? You'll probably be better off with the Macbook regardless.
|
|
#
¿
Jul 12, 2017 21:50
|
|
|
Given other mitigating factors like, say, carpet, I've found that the noise of an open office isn't much of a problem when pair programming. If you're not working alone, then rather than needing aural isolation to concentrate, you just need to be able to hear the person you're sitting next to.
|
|
#
¿
Jul 21, 2017 04:17
|
|
|
Privately tell the person who has the PII on their machine to delete it and be more hygienic. I handle that stuff like toxic waste on the unfortunate occasion that I have to, because it is dangerous to possess. Alternatively, remind the whole team without naming names. If they refuse, that's when you go over their head, because that's when it stopped being a matter of carelessness or convenience. The problem is probably not with the person having the data, but with the process that makes it possible for the person to have it. So be careful how you frame it. It does neither you nor the persons identified by the information no favors to put anyone on the defensive. Although too few people pay developers to care about security, we ought to care anyway as a matter of professional ethics.
|
|
#
¿
Aug 15, 2017 16:10
|
|
|
Still gotta try.
|
|
#
¿
Aug 15, 2017 16:24
|
|
|
Carbon dioxide posted:Help I got a Scala job after having gotten familiar with Java and I cannot wrap my head around functional programming at all yet. Especially in combination with Akka and the other frameworks they use. This recent article suggests the main concept is that the functional style is most strongly characterized by explicating the dependencies of your code.
|
|
#
¿
Sep 10, 2017 21:23
|
|
|
Every first programming language will teach you some bad habits. It's only a problem if you don't let your second programming language correct any of them.
|
|
#
¿
Sep 11, 2017 00:50
|
|
|
It is always appropriate to ask what the dress code is in advance.
|
|
#
¿
Sep 13, 2017 19:50
|
|
|
If the inputs to a given piece of functionality are obscured - because they're implicit or indirect, for instance - and the outputs are obscured - because they're mutations or side effects, for instance - then naturally it takes a great deal more effort to understand. Every moderately large system I've ever dealt with tended to accumulate unnecessary statefulness unless specific efforts to smash the state were fastidiously applied. So you're not experiencing anything unusual. You still need to put in work to understand it, of course, but your difficulty is a consequence of the design of the system, which makes it necessary to ingest more information in order to grasp any particular component. Ingesting information is work, and you can only do so much in a day. It's just not productivity. If it reflects badly on you, it's because the people who are considering you don't understand the problems they have created for themselves.
|
|
#
¿
Sep 14, 2017 16:19
|
|
|
The existence of more severe problems in other fields doesn't negate problems in the current field. Nor does the intractability of the problem suggested by an explanatory framework that encompasses the problem in question.
|
|
#
¿
Oct 20, 2017 19:28
|
|
|
Regardless of how you, personally, interpret them, poorly-defined attributes tend to be used in practice to reinforce the wrong kinds of biases.
|
|
#
¿
Oct 21, 2017 03:15
|
|
|
https://twitter.com/php_ceo/status/664237197365796864
|
|
#
¿
Nov 2, 2017 17:18
|
|
|
Best way to ensure you're writing unit tests is to write them first. Test-driven development, 's called. There's literature on the topic that you can use to get started. Then to ensure people care about it, in addition to CI, you may want to take the comparatively extreme step of setting up a pre-commit hook that runs the test suite.
|
|
#
¿
Nov 21, 2017 04:47
|
|
|
|
| # ¿ Apr 27, 2024 11:50 |
|
|
Skandranon posted:If his boss hasn't bought into the idea, setting up a pre-commit hook requiring tests is going to end very poorly for him the next time his boss commits code. This isn't a technical problem, he needs to convince his team/boss of the value of unit tests, not try to force it on them with clever tech. There may not be an easy way to do this, people don't often make great changes until something bad happens. Best way may just to continue putting tests on his stuff, and hopefully a (minor) catastrophe illustrates the value of them. I guess I was thinking of it more from a perspective of getting people who are already convinced to develop the desired good habit.
|
|
#
¿
Nov 21, 2017 05:02
|
|