ThorinJacobs

I've run into this when working with lambdas in particular. Say for instance I want to track the performance of a particular bit of code in a standardized way. I can write a method that takes a supplier and handles the performance tracking while calling the supplier and returning the result. This way tracked functions don't have a load of eg. timer initialization etc. If the supplier throws a checked exception, it should be caught and handled by the code that actually cares about the call, not the performance wrapper.

Unfortunately, because of the way Java handles checked exceptions, I can't feed the supplier with a lambda or any other method reference that I'm aware of that throws a checked exception and let it be passed up to the original caller directly. So I need to catch my checked exceptions and wrap them in an unchecked exception to catch. Not pretty.

There's probably something I'm missing but the language certainly doesn't go out of its way to help with this sort of thing.

Sure, but the migratory patterns of Canada geese are just a little off-topic, don't you think?

Have you considered Crapcha? https://crapcha.com/

If my experience in retail is any indicator you're lucky if that request gets approved....and even luckier if your manager remembers that they approved your request!

I agree with this sentiment and would like to see more this sort of this not just for moderators but for every "low skill" job. Especially the C-level employees and shareholders - no one should be asking anyone to do something without either A) doing it themselves so they know what they're asking or B) treating the workers as experts whose opinions and requests should be taken seriously.

I answered "both" because I'm not running all of the projects I'm working on and some of them prefer tabs and others spaces - so I just go with the convention that that particular project uses.

+1 - Another great example of difficult games as parody is I Wanna Be The Guy (https://en.wikipedia.org/wiki/I_Wanna_Be_the_Guy). Take all the existing conventions and stereotypes of difficult platform games and exaggerate them to the extreme.

This was deliberate on Douglas Adams' part [0]. It's all part of the joke. Other notable sections are where the game actively lies to you about being able to access a particular room (you need to try to enter several times in a row), and then sulks when you call it out and lies about the contents of the room.

[0] https://en.wikipedia.org/wiki/The_Hitchhiker%27s_Guide_to_th...

The notation for player death appears to be "JIGS-UP". Glad to see the classic Infocom sense of humor is present in the codebase too.

To add onto your comment - I'd also consider a work environment that automatically assigns the documentation, test-writing, etc. to a gender minority (or other minority) to be toxic.

This looks really cool and definitely fills a need I've had when doing web front-end.

Does the UI viewer work with dynamic content such as that loaded from a back-end (or say, from a sample .json file in the event that we want to skip the API call)? I've done a lot of work in WPF/MVVM applications where everything ends up becoming a ResourceDictionary and breaks the Visual Studio UI viewer, so I'm curious how you handle it.

Also, do you have any plans to incorporate a compatibility view? It would be really cool if I could select an item from a combo box and see what my UI would look like in (say) IE or Opera

Hi, clinically diagnosed here and while I can only speak for myself, the only time I've had an issue with someone who self-diagnosed was when they consistently brought up Problematic topics and played the "autistic, can't be offended" card.

My response to a self-diagnosed or clinically diagnosed person that was having a behavior problem would be the same, so why question? Why not just be kind and understanding?

One reason to suggest a smaller max character count is to assist those with impaired vision. I'm highly myopic and, while my lenses correct for it, I still seem to get eyestrain when using the default font/sizes in most IDEs. Bigger-screen monitors counterintuitively seem to make this worse, not better.

I can only imagine that this would be even more important for individuals with more severe vision impairments.

The main benefit for me is the ability to quickly and conveniently see the commit history and diff as well as branches' current position. If you're already comfortable with doing the same in CLI, then you're probably not going to gain a ton.

I like Sourcetree for this particularly because its buttons map fairly well to the actual CLI commands that it will be executing, and makes it painless to open a CLI terminal for instances where I want more fine-tuned control.

These are totally based on my own experience and may not make sense for everyone but:

- In the main projects I'd be working on, how many new files are necessary to consume data from an outside source (say JMS) and log the result.

- What is the frequency of your releases

- How long does it take for a minor feature request to make it from initial conception to delivery to the user

These aren't actually specific to a startup largely because I haven't been burnt by a failed startup. YMMV

I've had both good and bad experiences with checked exceptions - it can really depend on the team!

One of the parts of Lombok that really works well for me is that its notations are completely optional and fit many different levels of granularity as you see fit. Don't want sneaky exceptions? Don't use them!

I mostly end up using it to make my Java code feel like C# though...

I enjoyed the list and examples but I feel the hypothesis in the introduction is flawed.

All anecdata, but I expect those of us who read these sorts of lists will likely understand them quickly without needing examples. There's a large number of developers that are not reading software blogs and lists and are not applying much thought to their programs beyond "how do I meet the minimum requirements put forth in this user story". As long as those sorts of developer continue to be prevalent it's partly on the business to specify these requirements explicitly.

Tragically I don't see this changing any time soon.

I know the comments aren't meant for silly jokes but I'm very disappointed that there's no "Go 2 Considered Harmful" jokes here

I'm really excited for this year's AoC, and trying to get other devs at my work involved too!

Last year I tried to solve at least the first few days in a bunch of different languages, doing Red/Green TDD so I could learn how to set up a basic project and do tests in languages I was less familiar with. Still trying to decide if I should take that approach again this year or focus on getting every day done in a single new language.

How is complying to another's pronouns harming you in any way whatsoever? Meanwhile, you're harming them greatly by misgendering.

+1 on Advent of Code. Particularly useful are the sample input/output values that provide excellent unit tests. For 2017 I took the first few days and am working on solving them using classic red/green TDD in as many languages as possible

+1 and extra credit if you arrange so that it never occurs again. (Could be adding tests, could be improving communication to faster identify requirements gaps, etc)

The crux quote from the article is "Police departments that collect more in fees and fines are less effective at solving crimes."

What level of nesting are you referring to here? I ask because I experience the opposite - with more than one or two levels of nesting I have difficulty keeping track of the condition the block expects. Depending on the size of the method sometimes even one level can make me stumble a little.

+1 On this, and I'd want to encourage them to provide this feedback throughout the internship as well, not just at the end. Sure, sometimes they'll have suggestions that we've considered and decided not to do, but if it's a common question we should document.

For helping the interns, I'd talk to them about what they learned, what their next career steps are, and what subjects they're most interested in. Ideally, you have a mentorship program setup already where this has already been discussed, so this may end up being very brief. But even without a mentorship program, having good discussion about how you can help the interns aside from just having an extra line of experience on the resume is healthy for both sides.

For improving the program for future interns, I'd also ask them what they wished they knew when they first started their internship. For all of the above, make sure that it's a safe environment to have honest discussion - for instance state outright that they're not going to burn bridges by pointing out process flaws or talking about working at other companies in the future.

For software development - I favor books that are about good practices generally rather than books about particular languages which work well as references.

I usually recommend:

* Code Complete (Steve McConnell)

* The Pragmatic Programmer (Andrew Hunt and Dave Thomas)

* Clean Code and The Clean Coder (Robert Martin)

* The Mythical Man-Month (Fred Brooks)

* Test-Driven Development By Example (Kent Beck)

I also recommend blogs for more bite-sized knowledge. Jeff Atwood's blog at https://blog.codinghorror.com and Joel Spolsky's at https://www.joelonsoftware.com in particular have been helpful to me.

While on the train, I've started knitting instead of futzing around on my phone that I had been doing before. For me, it's been a very therapeutic exercise - a good time to deliberately shut out the noise of the internet and social media in general.

Now that I'm becoming more comfortable with the new hobby, I've started listening to audiobooks or streaming music while I knit - it seems to strike a nice balance.

Certainly the phone has enriched my life - it enables me to stream music and listen to audiobooks easily, but in my experience it's a dangerous tool as well, since it enables you to check social media more than is healthy. Everything in moderation I suppose.

There are a bunch of apps and websites that do this already. Google Play Rewards is probably the most reputable, but they're easy to find and advertise themselves aggressively.

The number one thing I love to see when I'm watching a tech talk that is focused on teaching or advertising a particular tech is the Bad Parts. Obviously you don't want to just bash the tech you're there for, but I've seen way too many demos that portray the technology as the One True Technology that will Solve All Your Problems and I usually approach tech talks from a place of skepticism.

Alice Goldfuss' recent talk on containers[1] is a really good example of what I'm talking about - she spends a good amount of time talking about what containers are, and why and when it would appropriate to use them, but she spends an equal or greater amount of time preparing the audience for what challenges they will encounter when implementing containers and talks about when you're probably better off without.

[1] https://www.youtube.com/watch?v=sJx_emIiABk

This is a really important aspect of good testing that doesn't seem to get as much attention as it deserves - the tests that have brought the most value for me are the ones that assert the business requirements, not the implementation details.

So for a little passthrough/orchestration class, it probably doesn't make sense to do much testing. For something that actually performs business logic, that's a prime candidate for testing. I've seen plenty of tests that just seem to aim to increase coverage, heck, I've written plenty of those myself - but at the end of the day, the benefit they serve after being written is probably minimal.