HN user

tericho

220 karma

[ my public key: https://keybase.io/terry; my proof: https://keybase.io/terry/sigs/Ko9fNjU_RHu8Hn_pZbcEDfmJ9V7-TVtj56fSaEqWFAs ]

Posts10
Comments86
View on HN

While it is easy to bash on an inanimate object, there are some very dedicated and empathetic people who care deeply about the project. Some of those people do this work in their off-hours and some to this work as part of their daily work activities AND also in their off hours.

I've been using Jenkins heavily over the past year since a client of our purchased the enterprise version. It was billed to me as a mature open source product that has been refined over the years by people trying to optimize their dev operations. While I'm sure some people really care about it, the user experience is so utterly disappointing it's almost impossible to imagine how it got to this state without neglect.

Even if you ignore all the complicated stuff, the web UI is embarrassing. While I don't suggest a "pretty" UI is necessary for devops, I would think you'd have a quick win just by having some people re-style the existing UI to make it look and feel like something built this century and not require a dozen clicks to get to important information. There are also bugs that are so painfully obvious it makes me wonder how they still exist. An example is if your Github branch has a slash in it (eg. feature/something) you get a 404 error if you try to navigate to that builds' results.

There are also features that appear to have almost no value yet are in the core UI and clearly took some time to build. The weather icons representing various permutations of previous build states is one ridiculous example that comes to mind.

I would respectfully suggest you run through some real world Jenkins experiences like the ones mentioned in the article. Also setting up a new server, configuring non-trivial SCM settings, debugging Jenkinsfiles, etc. To echo the article's sentiment - it feels like I'm constantly fighting with Jenkins to do what I need instead of being guided into a mature set of features.

Conversely - Octopus Deploy is a related product I have been using alongside Jenkins which has been an absolute joy to work with. Everything from initial setup to configuring its agent software on host servers has been straightforward. It has a simple, elegant UI that provides access to important information and actions where you would hope to see them. And most importantly - everything works. I have yet to encounter a bug or experience any broken UI states.

I'm glad to hear CloudBees is making some effort to improve things and I hope PMs like you continue to be involved in the community and solicit feedback, even if it's hard to hear sometimes.

It is rare because other systems that form these objects are VERY far away (trillions of KMs). Imagine trying to slide a hockey puck from one end of a hockey rink to the other, but have it pass through a small (~1M) circle at the far end from you. If you took 1000 attempts even randomly, you'd probably hit the circle by accident at some point. Now someone else is also shooting at the circle, but they are 50,000KM away. Suffice to say no matter how many attempts that person takes, it will be significantly more rare to see their puck cross through the circle than yours.

It's hidden way down at the bottom, but I found the Timeline to be my favourite part :)

Edit: Can't see to format it correctly, just check the original source.

I would really like to see an auto-reply feature similar to email out-of-office. Something you can set like "Back in 20 mins", "Coding until 4, PM if urgent only". Would mute the notifications maintaining your productivity, and your peers would still be in the loop instead of being ignored. Does anyone know if this can be done with a bot?

This article hits the nail on the head, but twice-a-day is extreme and not realistic for my position leading a development team. I found the mute button & fiddling with notification settings to be the middle ground. I do the same as you, turned off the red dot for all but mentions and it took away so much anxiety. I check in whenever I have time or take a break from programming. It's a nice balance.

I would argue from personal experience there's almost the same (or higher) likelihood of internal sources going down for other reasons since most people's IT departments aren't as efficient as GitHub's.

Highland.js 11 years ago

async.js changed my life, async programming can get out of hand in a hurry.

Highland.js 11 years ago

Is that a valid variable name? Would that mean Λ is unicode?

Our latest survey shows that full-time remote devs get paid 40% more than never remote devs

Anecdotally, I would suggest the demographic of employees who work remotely plays a part in this. In my experience, employers are more willing to let senior or "better" developers work remotely than less ambitious, less productive ones who need more day-to-day managing. Since quality developers (senior or otherwise) are generally paid more, I would presume this contributes to a higher average salary for remote workers.

As someone who struggles mightily with sleep I can tell you it's science not preference that makes you prefer cold. I can't find the original source of this fact but here is a decent alternative[1].

...scientists were able to lower skin temperature less than a degree Centrigrade without affecting core body temperature. The changes were dramatic. People didn't wake up as much during the night and the percentage of the sleep spent in stages 3 and 4 (deep sleep) increased. ... A 0.4 C decrease in skin temperature caused a decline in the probability of early morning waking from 0.58 to 0.04.

[1]http://www.sleepdex.org/thermoregulation.htm

What isn't wrong with using Notepad? If you use Notepad you are either a) too lazy to see what else is out there b) ignorant c) stubborn or d) don't care enough about your workflow to improve. There is literally no way you could form an argument that Notepad makes you more productive than any other popular editor.

Like most JS concepts, to me it's a "use it or lose it" situation. When I have to use them they are fresh in my head, when I move on to another project for 6 months that has no complex modules or uses a framework like Angular, there is no way I'll remember the intricacies. That being said, there is still a different between having used them and simply being aware of their existence, which I suppose could be made clear during an interview.

I started as a back-end developer (well, a software developer) and have made my way towards the client over the years. With my background in engineering (eg. learning how things work) I can confidently answer most of the questions. But I can see how modern "front-end developers" would have trouble with a LOT of them since today it's more about getting things to work than how or why.

That being said, I think it's a great list to work from. I would expect you can arrive at a fairly good understanding of a candidate's abilities based on how they answer the questions rather than if they can answer them all.