1,235 reputation
713
bio website none
location Portland, OR
age 50
visits member for 4 years, 2 months
seen Nov 15 at 9:24
Long time Java programmer. Currently work on software for cable boxes and DVRs, mostly Java some C/C++

Nov
15
comment Why would a company develop an atmosphere which discourage code comments?
It's all about how long it takes to comprehend the code afterwards. If having a comment makes it quicker for someone else to pick up the code and understand it, you should put them in there. The time taken to write and maintain them is completely irrelevant, most coding time (by far) is spent understanding with existing code and dealing with problems caused by a lack of understanding existing code. If you don't believe me, count the LOC in your project and divide by man hours to see how much actual code is typed an hour over the life of a project--it's not as much as you think.
Nov
15
comment Why would a company develop an atmosphere which discourage code comments?
On the other hand, I really love (not sarcastically) the requirement tracking comment referencing back into the requirement that inspired the code. I've used it a few times to find out why something was done a specific way to help me decide if a certain change was viable or not--also when the requirements change being able to track where in the code existing parts of the requirement were implemented is really a time saver.
Nov
14
comment How can Swift be so much faster than Objective-C in these comparisons?
This answer doesn't hold water at all and is horribly misleading. OO is not really slow, in fact the fastest systems you'll find around are going to be C++, Java and C# and the style (heavily OO or not) of programming will have very little to do with the resultant speeds unless you have really bad code.
Nov
14
comment How can Swift be so much faster than Objective-C in these comparisons?
@syrion I thought about the python thing too. I think the point is to avoid comparison with a fast language. Python is one of the faster scripting languages I've seen around, but last time I checked it was still 10x slower than Java and 20x slower than C for most stuff. If they were to stick either of those in there Swift wouldn't have looked quite as swift.
Oct
30
comment Use constructor or setter method?
I would say that if it needs to be set for your object to be valid, put it in every constructor... if it's optional (has a reasonable default) and you don't care about immutability, put it in a setter. It should be impossible to instantiate your object into an invalid state or after instantiation put it into an invalid state wherever possible.
Oct
7
comment OOP: Behavior + Data, but what about 'validation' behaviors?
If you go beyond trivial validations (like null checking or basic range checking) you are probably right, they aren't behaviors and don't belong in the class. Often validations can be attached to a class through external metadata (annotations and/or data files) and can therefore be more easily manipulated, adjusted and applied at different levels (UI and database, for instance). Only validations required to ensure that the class is a valid object should be coded directly into the class.
Sep
24
comment Is using `continue`, `break` in non-`switch` loops and `?:` bad practice?
Surprises are bad. If you check conditions at the beginning of a method and return, and the structure is clear and expected, it's fine. If you bury a return in the middle of a nested logic loop it will surprise someone someday, which is bad. I had my first boss tell me that ?: was "Bad" because nobody ever used or understood it and therefore it would take extra time to understand the code. If he was right about the assumption, then his conclusion was also correct. I hope he wasn't.
Jul
15
comment Is it a good idea to “#define me (*this)”?
As an alternative comment--I think the pattern of identifying members with this. is pretty bad. I really don't even like using m_, the reason is that it can be wrong. One refactor where you forget to change the name can cause a LOT more work than just letting your tools do their job. (I don't know about C++ IDEs, but in Java/Eclipse members, statics and locals can easily be differentiated at least 3 ways--by color/font, hovering and ctrl-clicking. Perhaps your team would be better served if you spent time looking into more appropriate tools?
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.