Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:Practice Practice Practice (Score 1) 347


Also kinda said it above somewhere, but I think it's really important to set a standard early on. If you accept shitty work from them, they'll keep submitting shitty work (either because it's the path of least effort, or they just don't know it's shitty).

Do code reviews, enforce them, require their work to meet a certain level of quality (and kick it back when it doesn't), and most people people will rise to that standard. If you enforce that all public methods must have good comments, and consistently kick back code with no comments or shitty/ineffective comments, people will start habitually doing it right because they know they can't get away with doing it wrong.

Comment Re:Poor (Score 1) 347

I think this partly falls on the people leading a technical project. Yes, programmers should take initiative to produce the best code they can, and many do, but people have a tendency to the path of least resistance, and even when they are legitimately trying, they may lack the experience to intuitively know that what they are producing is sub-par.

Good technical leadership sets _and enforces_ standards. This should happen at every level, with the quality of the standards increasing as the experience of the people driving them increases. If someone produces sub part work, it should get kicked back to them to fix and re-submit. This is a hard sell for management because they see money and time being spent re-doing stuff that "works fine" during the initial learning period, but if you set the bar early and make it clear what will and won't be accepted, people will rise to it (or demonstrate that they are unsuitable for the role they are in).

Comment Poor (Score 5, Insightful) 347

Ideally, I want to give them some sort of practicals to do to articulate and demonstrate this, rather than just "present" stuff on best practices...

This raises the question of not only what you'd teach -- whether it's variable naming, modular programming, test-driven development, or the importance of commenting -- but also how you'd teach it.

I think this is already going down the wrong path. Those are just technical skills and practices that will be picked up over time, and some kind of workshop isn't really the place to learn them imo.

The important differences between a new guy and someone with a decent bit of professional experience under their belt isn't so much in technical skills or adherence to best practices, but it's more of a mindset and general direction thing. Once you've seen a few projects from start to completion, you start to recognize certain patterns and points where things can go really well or really bad. Once you've worked on a bunch of different teams, you start to recognize how different people contribute to a team dynamic and the various ways in which a team functions. You start to understand how your job integrates with the rest of our department and the rest of the business, how the whole management structure works, and what really drives most technical decisions (hint: technical merit is often the last thing driving a decision).

The problem is, you can't really teach that. So I guess my answer would really be very generic "how to be a good employee" type stuff: Take ownership of your problems, check your ego, play well with others, etc. Being a more professional programmer has little imo to do with being a better programmer and more to do with being a better professional. You become a more professional programmer by learning how to have a productive meeting with management about your project, not by learning the magic of continuous integration.

Comment Re:It happens, but way too commonly with google (Score 4, Insightful) 150

I've been involved in refactoring lots of software to replace dependencies on dead or obsolete tools and libraries, some of which were very expensive. Open source projects stagnate and die, but businesses go bankrupt, shift directions and discontinue products if they become unprofitable.

Determining the stability of a product and the impact to your business if it goes away is (or should be) part of the business decision process.

Comment Re:It happens, but way too commonly with google (Score 2) 150

There's nothing wrong with cloud-based services, as long as you go in with your eyes wide open to both the upsides AND the downsides.

Agree entirely. It's a risk and business management decision as much as a technical one. Relying on 3rd party services is obviously (or hopefully obviously) a risk, but risk is a basic component of most business.

Comment It happens, but way too commonly with google (Score 5, Insightful) 150

These days it's hard to write anything non-trivial without relying on something that will be hard to replace if it goes away, that's just a reality of modern software design. You can minimize the risk with abstraction and try to rely on open standards with multiple implementations, but at some point you have to just accept the occasional puzzle piece change as part of the business and move on.

That said, google pulls this shit all the time. Using a google API or service for anything critical would imo be a huge risk given their long history of suddenly killing things.

Comment Re:Lets hope its better than the last few series (Score 1) 153

It's a controversial opinion, but while I thought season 7 was mostly terrible, I actually liked where they went with the last season and actually hold it up as a rare example of a show managing to breath new life into something that's gone stale by introducing a major plot development near the end.

Comment What's the big problem? (Score 5, Insightful) 675

As a Canadian I really don't get this. We've had chip and pin here for awhile, and while the initial adoption was a bit rough, it generally works fine.


Reader says "insert chip in the bottom".
You insert chip in the bottom.
Reader says "enter pin".
You enter pin.

Painstakingly slow

I've noticed some readers are slow, but this probably has nothing to do with the chip, the merchant just has a shitty system. If you're talking about the process being slower, ok yeah, by about 10 to 15 seconds or so.

Less secure than the alternatives

What alternatives? Getting a signature that no teller ever verifies or checking the name against your ID (which again, never actually happens)?

Not saying chip and pin is perfect, but I really don't get why this is such a big "disaster".

Comment Re: Maybe they just don't like the shows? (Score 2) 858

Meh, guilty as charged to pretty much all of that.

If what you said works then I'm envious.. I accepted having to choose between sitting through some crap while cuddling or no cuddling and possibly a speech a long time ago.

I do complain about the shows though, it's no secret that I don't like them. Why women (or at least the subset I've known) absolutely insist on forcing us to watch stuff with them that they _know_ we hate is beyond me, but it's a thing and I (like I suspect many others) gave up fighting it a long time ago.

Slashdot Top Deals

"Being against torture ought to be sort of a bipartisan thing." -- Karl Lehenbauer