1,243 reputation
613
bio website none
location Portland, OR
age 50
visits member for 3 years, 10 months
seen May 12 at 17:37
Long time Java programmer. Currently work on software for cable boxes and DVRs, mostly Java some C/C++

Sep
17
comment Is a large increase in velocity realistic in a Scrum environment?
Honestly your manager should be sent to an agile/scrum refresher, he's missing the point so severely as to make me believe he's never even been given the chance to understand how agile works--what I mean is everything you said about his actions goes against agile practices, he should be given the oppourtinity to understand it from the ground-up.
Aug
12
comment Why Java doesn't make use of encapsulation with some classes?
What a fantastic way to view it--constant objects. Never heard it that way before. Color me impressed.
Aug
12
comment Why Java doesn't make use of encapsulation with some classes?
I'd make the statement even stronger, a public final variable (static or not) is exactly as "Safe" as a getter and I'd perfer the immutibility over a setter/getter pair. Setters are just about always a bad idea (Immutable is good--and if it can't be immutable the method that "Sets" it probably deserves a little business logic too), If you need a getter you might as well make it public final, but doing neither is preferable--don't ask a class for it's data, ask a class to do something to it's data.
Jul
26
comment Java: The best way to learn it when MOOCs and books are not enough?
1) Just practice. 2) Use Eclipse to help you get used to java syntax. Use ctrl-space a lot. This is critical! 3) Arrays (like Exceptions and generics) are unique structures in Java, just take some getting used to. Take them on slowly. 4) Google it. Seriously. 5)constructors are just methods with a few special properties (slightly different syntax and that they are invoked with the "new" keyword). 6) Google
Jul
26
comment Let go yet again from another job, should I give up on programming?
By the way, I think that being "Slower" is not bad, it generally means that there are speedups in other parts of the development process--sometimes HUGE speedups (such as not having to re-write the entire spagetti codebase). Problem is, such savings never gets attributed to the original coder who just went that extra effort every single time to refactor and clean up his crap and that of others.
Jul
26
comment Let go yet again from another job, should I give up on programming?
People with ADD tend to make excellent engineers. We do tend to be slower, but that's because we can't accept things that seem "Wrong". In our realm "Wrong" equates to copy and paste programming or programming that doesn't make sense (isn't maintainable)--for us programming is an art. This can make us quite slow compared to people who are willing to compromise. Strangely, I've found I work very well with C&P programmers, I tend to be able to improve their skills over time while delegating those jobs that just seem too "Messy" to solve correctly in a good ammount of time. Play to your strengths
Jun
21
comment Finally block for methods - is it a bad idea?
Working with a team is different thatn working alone. You describe working alone (which is a perfectly valid scenario) but your assumptions don't apply to a team working on a largish project. If I code something using a new feature, my teammates (even overseas contractors) must know it (and there are always programmers anxious to try new language features, so it will happen). I think that when you are working alone you should just choose one of the many existing languages that have exciting, new constructs--you might be able to implement this feature in scala yourself, give it a try!
Jun
4
comment Why do we use story points instead of man days when estimating user stories?
@Glorgio Yeah, that's pretty much what I'm saying. Unless you are going full agile, any one dicipline doesn't help much. If you are full agile you kind of need the stand-ups to keep on track because so many things are moving at once--also full agile doesn't really have a significant manager more of a coach, so team coordination is more important. The worst use of it is telling your manager what you are doing every day--that shouldn't even enter into it and is utterly pointless from a development point of view.
Jun
3
comment Why do we use story points instead of man days when estimating user stories?
@Giorgio You can get a benifit from stand-ups alone, but not explaining everything you did--instead discuss problems you are facing, roadblocks and things you can use help with. It's not to let your manager know you are keebing busy, it's to communicate with team members--a "Manager" need not even be involved, but you will get a lot more benifit from implementing many of the other diciplines such as keeping your whole core team available to you all day long (co-locating the team) or having a customer available at all times.
May
25
comment In languages that don't allow underscores in integer constants, is it a good practice to create a constant for 1 billion?
I've had various people tell me that it's PROBABLY best to use no numbers in your code whatsoever (possibly excepting 1 and 0 which make nice loop terminations). I don't know if they really believed it, but it might be an interesting experiment.
May
15
comment Is it poor programming practice to pass parameters as Objects?
People do small things quicker in Ruby and dynamic languages--say twitter. Large things not so much (say twitter). There are appropriate tools for every job, Ruby isn't the best answer for them all--are you suggesting it is?
May
15
comment Is it poor programming practice to pass parameters as Objects?
I've worked in Ruby and Groovy. Although I like coding small tasks in them, they are horrific when dealing with a poorly documented library or integrating with code from an adjacent team (that you aren't in contact with). Not enough information in the code is the reason. People get stuff done in Basic, Fortran, Cobol and machine language too--all have their place, many have advantages and disadvantages, but programmers Get Stuff Done isn't a good argument to chose any of them for a given task.
May
8
comment How do you unit test private methods?
I don't love this option, but for many it's probably a valid solution, not worth the downvotes.
May
3
comment Coding style (do more, then simplify)
I understand what you are saying and I agree it's possible, I've just never seen it. For instance, I've been using (and really enjoying) Groovy's closures, chaining together closures to evaluate some path is really fun, you can fit a bunch of stuff on one line. I consider it write-only though, it's virtually unreadable even though it replaces 10-20 lines of code. The longer code can easily be organized and even placed into a single method call with a name that is infinitely more understandable than the closure it replaced--just not as fun to code.
May
2
comment Coding style (do more, then simplify)
Are you really sure the second is more readable for everyone that will run into it? Enough to make a code change worth while? (I've known developers who had to ponder over the ?: operator--simply because it's rare). The compiler is certainly as happy with one as the other. Honestly I might leave the first one in there--at a glance it more directly shows intent and the second might be an example of unnecessary brevity. Might.
Apr
30
comment Coding style (do more, then simplify)
Perhaps, as I said I've never seen too much verbosoty without redundancy, but it could be done if one really tried I guess. I'm a little curious to see what dry code could only benifit from pure reduction rather than reorginization though. If you have an example I'd be quite interested.
Apr
29
comment Coding style (do more, then simplify)
Although I admit it's fully possible, I have never encountered code that was DRY, did not take unnecessary actions and was too long winded--in like 30 years of programming. I have seen a lot of code people THOUGHT was dry that wasn't--It's not just combining identical code, it's searching out similar logic and finding ways to combine it. All the other code I'd call "Long Winded" was just not broken up enough into functions, methods or classes--orginizational problems but not problems with the amount of code.
Apr
25
comment If a variable has getter and setter, should it be public?
Mutable state is acceptable, but again you should ask your object to do something for you, not do somethign to your object--therefore when you mutate your state a setter is not a great way to do it, try writing a business method with logic in it instead. For instance, "move(Up5) rather than setZLocation(getZLocation()+5)".
Apr
25
comment If a variable has getter and setter, should it be public?
@RobertHarvey That still means you are exposing properties. My entire point was that exposing properties should be avoided, and when necessary you should try to restrict them to getters and make your class immutable. If your class is immutable why would you need code in a getter--and therefore it follows that you might as well not have a getter. If you are incapible of writeing a class without exposed mutable properties then yes, a setter is always better than a writable public variable (and getting shot in the foot is always better than being stabbed in the gut).
Apr
25
comment How to reject a code review that you believe is unnecessary?
I suppose you could say that it must either pass a test that otherwise fails (and that test needs to be supported by a documented business rule) or it needs to increase readability (as perceived by reviewers) and/or reduce redundancy. Perceived performance is NOT a valid reason for a change unless it meets requirement 1 (is a business rule and fails a tests).