tetonraven

8 ms·

1.
by tetonraven 10y ago
C#
2.
by tetonraven 11y ago
Most important is to ignore a candidate's proven ability to deliver real solutions and instead focus on contrived tests that bear no resemblance to the actual work they'd be doing.
3.
by tetonraven 11y ago
Maybe some detail would help. I have interviewed and hired people, been a dev team lead and manager. I would consider a such a candidate enough to at least get them on the phone and see where it goes. Just wondering if I'm alone here (
4.
by tetonraven 11y ago
Is there any common resource that people use for judging reputation of these programs? For what it's worth, the context for my question is for one in Boulder called RefactorU. I've been a web developer for (well, a while) but my w
5.
by tetonraven 11y ago
Any detail on why not? A categorical or conditional no?
6.
Would You Hire a Bootcamp Grad?
2 points by tetonraven 11y ago|7 comments
7.
by tetonraven 11y ago
Oh. And definitely bringing that domain knowledge (medical) is an advantage to getting into your first programming gig.
8.
by tetonraven 11y ago
Yes! I never got a CS degree (or any degree, actually) and I've been professional programmer for more than 20 years. I've also been in the position of interviewing/hiring developers and never paid any attention to degrees. I
9.
by tetonraven 11y ago
First off, each person shouldn't have "their" stories. The stories in the sprint backlog should be owned by and worked by the entire team. Second, not everything needs to be a story or a task in the backlog; agile isn't
10.
by tetonraven 11y ago
The goal is to have a potentially shippable product increment at the end of each sprint. You don't have to release it to production; but it should certainly be made available for review/feedback by stakeholders and either custom
11.
by tetonraven 11y ago
In other news... Studies show that eating hamburgers is always the healthiest choice for any person on any diet. Read more at McDonalds.com.
12.
by tetonraven 11y ago
Another thing. Don't create "technical stories". They are not user stories and that undermines Scrum in a variety of ways. One important consideration, too, is this... Even if it's completely horrid code, unless there&#x
13.
by tetonraven 11y ago
The first step, of course, is to stop accumulating it. As for dealing with what's already there... The right approach is to chip away at it incrementally, cleaning up related code with any new work you take on; among other benefits, th
14.
by tetonraven 11y ago
I would suggest committing to just try it. If you give an honest try at putting quality and testing center-stage in your development, I think you'll start to see the value and eventually get hooked on it. Start with unit tests and grow