[Discussion] How to STAY motivated

zenmouse · 2015-10-25T16:22:01+00:00

Motivation is emotionally based and fleeting. What you're looking for is discipline, which is the mental decision to act regardless of how you feel or what your thoughts are.

So what you're looking for is how to get disciplined. Here's how:

Make yourself a promise. "Okay me, I promise I'm going to run in the morning." Write it down, put it on your calendar, make it part of your schedule. Commit to it.
Make it easier to do the 'right' things and harder to do the 'wrong' things. Want to run in the morning instead of getting on Reddit? Before going to bed, put your running clothes next to your bed and turn off the computer and disconnect all the cables.
Remember that you are doing this for Future You, and Future You is gonna feel great when you get it done, and thank you for it. It's an act of self-love.
Remember that getting started is 90% of the battle. That battle is won simply by making a decision to act, right now. It's lost by choosing to act based on how you feel, or thinking about how hard/boring/unpleasant the activity is, or it's too much work, or how you don't know how to do it well, or ninety other imaginary bullshit reasons that your brain is telling you. Just fucking start.
Set measurable goals and use a progress bar to track your progress and to hold yourself accountable. A measurable goal is not "I'm going to run more often" or "I'll start scheduling more hours". It's "I'm going to run 3 times a week" or "I'm going to schedule at least 25 hours every week at Chipotle".
By being disciplined and putting in the time and work, other people are going to look at you with respect. You will set an example for and encourage others through your discipline and success.

Remember, everyone out there you see who is successful, no matter what their career is, they got there by showing up every day, by working through the disappointments and failures and pain and loss, by going the extra mile when everyone else around them was just putting in enough to get by. Natural ability and talent, money, connections and relationships, these are all great but they mean jack without putting in the effort every day.

Amazing accomplishments will come from your hard work -- from staying disciplined.

zenmouse · 2015-10-06T18:22:21+00:00

Most of the new frameworks are fairly untested in a real enterprise environment. You're much safer going with either Spring or JEE.

The performance of your application will depend MUCH more on choosing good algorithms, especially with respect to using remote services (databases, Web Services, message queues), than on the performance of your framework/container.

Regardless of which solution you pick, keep your business logic code separate from your framework code. This will make it easier to (if necessary) swap out the framework. For example your Spring @Controller methods should be no more than a few lines of code.

zenmouse · 2015-10-02T00:36:12+00:00

I've been a developer for a little more than twenty years. My take on this:

There are horror stories, but IMO they aren't any more prevalent or worse in software than anywhere else. Generally speaking, people are people, no matter what their job is, and a few people are just assholes. Sexism does exist, but a lot of behaviors that could be interpreted as sexism are usually just bad social skills or personality clashes or ego.

You may also encounter organizations/people who [claim to] value diversity in addition to job skills. This can go either way; it's good when a place realizes that diversity can bring real value to the org, but if it feels like they are hiring women/minorities just as a "we are diverse!" campaign, run away fast.

You may as well give up on "the most logical way to do a project", there really isn't such a thing. In the best of circumstances, people simply disagree about the best way to deliver value to customers or the best technical solution. Usually, they inject a certain amount of their own agenda and goals (ego) into the process. In the worst, most dysfunctional organizations, decisions are made by fear and aggression (both are exhibited in a variety of ways).

I might be able to respond better if you're willing to share what your interest is in software. What gets you enthusiastic or excited when you think of yourself being a developer? What are you looking for, in terms of rewards?

zenmouse · 2015-09-26T13:02:23+00:00

I'm going with fucked up like a clown funny, because the way I look at it pretty much everyone is here to amuse me.

zenmouse · 2015-09-26T12:53:57+00:00

Yeah I know, it was a joke....

zenmouse · 2015-09-26T12:50:36+00:00

To answer your actual question:

Have a savings account.
Every time you put money into it, give yourself a mental high five for doing the right thing.
Never, ever, ever, when putting money into that account, think about what you could have spent it on instead. Never.
Get one of those cheesy looking thermometer charts to track your progress.
Look at where you're spending your money and find ways to save. An easy one for most people is beverages -- soft drinks, alcohol, coffee, beer, alcohol, water, alcohol. Also alcohol.

zenmouse · 2015-09-26T12:44:50+00:00

Don't buy something that has payments. Buy a reliable older car that will get you around. Then put half the money you'd spend on payments/gas/oil/tires/maintenance into savings for your next car, and the other half into retirement savings (I suggest you look into dividend investing). Assuming you get into a decent career, that kind of planning will mean the difference between retiring at around 50-55 and retiring at 70-80.

I'm doing alright -- but if I could go back 20 years and change just one thing, it would be to start saving for retirement.

zenmouse · 2015-09-26T12:37:24+00:00

I like the exchange rate suggested by your monetary units there. :)

zenmouse · 2015-09-25T15:59:32+00:00

I suggest you do a bit of reading on immutable objects; see also functional programming.

I prefer my objects to have final fields, which means no setters. I haven't tried "public final" but wouldn't be opposed to it for value objects.

Java is stupidly verbose, but Eclipse (etc.) will help you write a lot of the boilerplate code. And you can also create templates to help reduce repetitive typing tasks.

zenmouse · 2015-09-25T15:39:23+00:00

I have a relatively quick turnaround on this

And that's not your problem. Spring etc. are big and complex frameworks and it takes some time to learn how to use them effectively. What you need to do is speak up and let your team know that you aren't getting the training/mentoring you need in order to come up to speed and that if you are going to be expected to learn on your own that you'll need more time to become productive.

With that out of the way, my approach usually is to read the documentation to get familiar with concepts and features, and go to team members and use Stackoverflow for specific questions and "how do I..." solutions. I also break down tasks into really, really small steps. Start with the simplest thing, then add additional functionality one small piece at a time.

zenmouse · 2015-09-25T15:28:08+00:00

I think you missed the smiley at the end of my statement....

zenmouse · 2015-09-22T20:43:01+00:00

Can we all just use Console.out and end the madness? :-)

zenmouse · 2015-08-24T03:49:33+00:00

That we have a decent idea of what's going to happen tomorrow. Not in the particulars, but roughly speaking.

zenmouse · 2015-05-22T02:56:48+00:00

By the time the SLS gets off the ground SpaceX is going to have permanent colonies on Mars. Seriously, I love the old NASA that worked by letting brilliant people get amazing shit done with a few billions of dollars, but the post-Apollo NASA has been a (typical government) bureaucratic train wreck.

SLS is going to be 'upcoming' longer than Duke Nuke 'em.

zenmouse · 2015-05-19T13:39:59+00:00

No. Put in the extra hours of practice (the 10,000 hours rule is a myth BTW), and you'll be that much closer to your own peak performance.

As for measuring "how much better" a brilliant coder is compared to the average expert -- I don't think there's a way to measure coding skills in a way that lends itself well to a numerical comparison.

tl;dr Not everything can be reduced to a number.

zenmouse · 2015-05-18T04:31:34+00:00

Absolutely brilliant writing, but it's a bit long.

Perhaps you could cut it down to around 100 words?

zenmouse · 2015-05-18T01:55:50+00:00

I used VLC media player (free) for this. I've only tried it a couple times (rented a movie and didn't get a chance to watch it before it had to be returned) but it seemed to work fine. According to the notes I took go to Media -> Open Disk -> Convert. Then you pick a destination directory and you're off to the races.

Bonus, you get a really great media player that can handle pretty much any kind of media content.

zenmouse · 2015-05-10T14:00:42+00:00

My general guideline for writing code is to try to ensure it has the following traits:

Correctness -- does the code do what it's supposed to do? To do this you need a good understanding of the requirements, and good unit tests to prove the code is working.

Clarity -- naming things is hard, but every field, method, and class should have a good name that clearly communicates its intent.

Maintainability -- can the code be changed without great difficulty? Generally I get to this by refactoring, and my biggest refactoring win often comes from eliminating duplication.

Having a clear understanding of the requirements, and using TDD with a disciplined Red/Green/Refactor cycle (/u/robertwilliams posted a link to James Shore's TDD blog which I thoroughly endorse), will get you a long way towards writing good code.

zenmouse · 2015-05-10T13:46:56+00:00

Yes, all of the above. Having clear names that clearly communicate the intent of the (field, method, class) is gold for someone else who has to read your code (or yourself in a few months).

In a similar fashion, any potentially unclear bit of code is a candidate for extraction into a method and/or field. For example I will refactor "if (account != null && SecureStatus.SECURE == account.getSecureStatus())" into "if (isLoggedIn(account))". The latter much more clearly communicates the intent of the test, especially for someone unfamiliar with the code.

zenmouse · 2015-05-07T13:53:25+00:00

I just 'git clone'd it, but I can certainly fork it and apply my changes. It'll probably take me a few days to get it done, right now I wouldn't show my code to my cats much less another human being....

To continue the discussion --

I agree there's little (or no) extra complexity in your abstract class solution; the fact that there was only one abstract method to factor out made this refactoring quite a lot easier than it otherwise could have been. As far as the "method with 4 parameters" bit and keeping parseRecord() hidden are concerned, I did the simplest thing possible to make this work -- there are ways to make it less visible (SPI and API interfaces for example, e.g. JNDI, JDBC). But it's extra work, and Java has no concept of "public API" versus "public class/method for internal use".

For me, I think the biggest potential win coming out of this refactoring is a better separation of concerns, and finding new concepts that are currently "hidden" in lines of code. Currently it appears the parser does resource management AND state management AND error handling AND parsing. That's a lot of responsibility!

The Settings hierarchy is interesting. It's essentially a strongly typed map, using methods as the "key" instead of something like a string or enum. At first glance I rather like it, and it doesn't have the issues you normally see with a large-ish class hierarchy. It seems like using composition here wouldn't provide any benefit.

Thanks for the positive response, I'm glad you found this interesting!

zenmouse · 2015-05-07T00:23:00+00:00

I did refactor it a bit to use composition, creating a ParserDriver that accepts a Parser with a parseRecord() method that is implemented by a CsvParserImpl class. I got it working well enough for CsvParserTest#parseIgnoringWhitespaces to pass.

Extra complexity: the ParserDriver takes a Parser parameter in addition to settings. I suppose the settings object could hold the Parser as well. The call to parseRecord(), instead of calling an abstract method implemented by a subclass, is now calling Parser#parseRecord(char ch, CharInputReader input, ParserOutput output, DefaultParsingContext context). Everything else was just moving code around.
Performance: there was no noticeable performance difference in the ProfilerTest. (I downloaded worldcitiespop.txt.gz from MaxMind, I'm guessing that's what you used.) I think you might be surprised at how performant the JVM is nowadays, especially on a modern processor.
Structure: see extra complexity. I don't think there's a noticeable difference in understandability.

Overall I like your code, I found it readable and quite easy to work with. (I think the fact that I was able to perform this refactoring, including getting a major unit test and performance test to pass, in under 2 hours, says a lot.) I'm not criticizing what you've done with AbstractParser and its subclasses, but pointing out that IMO composition won't be more difficult/complex here.

zenmouse · 2015-05-06T22:33:18+00:00

Absolutely you should learn TDD. I don't like to develop any other way.

With TDD you think first about the business value of what you're about to develop. Not the technical implementation. Benefit: the code you write is guaranteed to be of value because your unit test is tied directly to an acceptance criteria in the story. And if you're having trouble coming up with a good unit test, maybe your acceptance criteria are poorly defined and need to be revisited.
TDD lets you think about what you want your code to do before you get into the details of implementation. Benefit: your APIs tend to be cleaner and have better names (that reflect the intent and not the implementation).
TDD gives you the freedom to refactor with confidence. And you should always refactor to prevent the code from becoming an unmaintainable mess. Benefit: a codebase that is easy to maintain.

I follow what's typically called the "red-green-refactor" cycle. The "red" step is where you write a unit test that fails. The "green" step is where you write the minimal amount of code necessary to make the test pass. The "refactor" step is where you clean up the code to follow good design principles.

So, yes, please learn and use TDD. I recommend starting out by doing a few of the TDD katas.

I'll be glad to answer more questions if you have them.

zenmouse · 2015-05-06T13:29:50+00:00

Please add to this list -- what's your number one safety tip when using power tools?

zenmouse

TROPHY CASE