|
I feel your pain, been there myself. Sometimes still think of things to do which will simply take too long, or where I'd need to study up on special libraries/frameworks/etc. and again "take too long".
But if I've learned anything, it was always from making mistakes. All the courses, the books, the tuts, the examples, etc. ... all of them ... bar none ... only ever guided me into what I actually needed to "learn". It was only once I actually "did something" when I truly started to get the hang of this thing called programming. And even then, I still made lots of mistakes (still do even decades later) - you need a thick skin and the ability to laugh at yourself (else you'll get your feelings hurt and go mad).
The trick for me was to start off small. Partly I was fortunate, since my aim was for 3d modelling & rendering - in most cases my "projects" were nothing more than extensions to existing programs. So finding some idea which could easily be implemented in a matter of weeks (or even days) wasn't that difficult. It was only around 5 years after starting that I did anything closer to 1000s of LOC, and even later when I needed to combine several different aspects (like tying to a DB, adding web interface, etc.). But this does make newer "big-picture" ideas more difficult to do on your own, usually really impractical without a full team to work on different parts. What makes these ideas worse is the fact that I'm not full time on them, I've got a day-job (diagonally related to programming) so the hobby programming ideas always take a back seat.
My advise: Try to be courageous, don't let any critique get to you (use it instead to try and learn). Try to see if parts of your "big-ideas" can be implemented on their own. E.g. perhaps look at just making a parser for the google data first, or a DB to hold such searchable info, etc. etc. Don't worry too much about making each into the Mona-Lisa of code, definitely don't waste your time in optimizing them to death (that effort would most likely be completely useless). Next try to see if you can modify these to combine them.
You're most probably going to run into issues, I can nearly guarantee that, and these are when you realize the "mistake" and then learn to make it "better". Note, "mistake" is not necessarily something you did "wrong", just that it either doesn't work in your scenario or it makes something else cumbersome / inefficient / unworkable / etc. Even if you did everything "perfectly" and others pray to your code as a new religious tome, it might still be worthless.
Sometimes a bad piece of code becomes a necessity to make something just "work". As an example I needed to parse a hierarchical tab-delimited file for display in a searchable tree-view. Since this file was what a program was using for items to be placed in a workshared 3d model (being concurrently worked on by multiple people) the flat file needed to be updated nearly immediately and searches & edits shouldn't be "slow". There was a way to change the program so it used a DB instead, so I tried the whole thing from a client-server DB idea. But that turned this seemingly simple project into multiple big projects. Spending months on it and in the end finding that such was simply stupidly slow to load, search, edit, etc. Spending yet more months on tweaking to try and get performance to acceptable levels, researching, finding tricks, web searches etc. Redesign the DB structure, add extra indexing, modify queries, changing queries to server procedures, caching results, etc. etc. etc. Nothing worked. Finally I gave up and just went with a straight forward parsing of the original flat file into a in-memory n-tree with hashtable backing for key loopuks (and a "fuzz" text search on names and descriptions), took around a month to implement as straight-forwardly as possible - used a lot more RAM, concurrency locking was nearly non-existent, etc etc etc. But it worked, and all the users were happy with the performance, still used years later (very few bug reports and/or feature requests).
I'm very embarrassed by the code itself, it's a hack, and not a very good one at that. It's still a pet peeve of mine to try and turn such collection data structure into a more formal hierarchical catalogue structure, but every time I try I run out of time and/or think of doing it a slightly "better" way. I must have around 20 versions of my attempts floating around my backup discs somewhere. Few of them actually work, even less are something I'd feel comfortable sharing, none I'm proud of. But boy, did I learn some huge lessons in that time.
|
|
|
|
|
Let me give you the outsiders view of INTUIT.
They started with an electronic way to balance your checkbook!
It was horrible code. But it fit a need.
They parlayed that into QuickBooks. At first the accountants HATED QB.
Because it let normal people (like me) do accounting. And do it fairly well,
or fairly wrong, depending.
Then Intuit focused on tools for the Accountants, so they could process the files,
etc. (My brother is a CPA, certified in QB). For many years QB Sucked for multiple users.
They made MILLIONS along the way.
Their QB Online. Kinda sucks, and is missing key, obvious features (Like an External Customer ID
to link customers in QB to customers in the clients DB, in a unique fashion). OMG. They missed that?
The point of this dribble is that Perfect Software doesn't always sell.
Don't focus on perfection, focus on getting it working, and scratching the itch.
It can always be rewritten later, if it is successful. QB was rewritten about 4 times.
So, you are running into the old paradigm: Fast, Right or Cheap: Choose 2! (You cannot optimize for all 3). Since you are doing it yourself, and without funding. CHEAP is now there.
So, you are contemplating your choices.
Do I do it RIGHT? Or do I do it Fast? (Getting it finished).
How much is an unfinished movie or book worth? (About nothing, there are a zillion of them).
[Ignore getting paid (raising money) to finish a good story, unless that is your intent]
Hopefully this helps you see where you are at.
At one point in my career, we released a stable (but unfinished product), with the ability to push updates out to the clients throughout the US. We were YEARS behind the competition. But in the first year, we averaged 2.5 updates per week EVERY WEEK. 99% of the updates were stable and added missing functionality that reduced work effort of the customers. Within a year, we were on par with the other software. And 6 months after that, we were ahead of them, and all the buzz. And we never stopped for a couple of more years, when they closed up shop. By then our updates were down to 1-2/month, but we did not need so many.
A Stable framework that is safe/easy to update goes a long way. Updates are guaranteed to happen.
To me, focus there, the rest will take care of itself.
What is wrong with Publish/Feedback/Develop/TEST/Publish... as a cycle? It will get you where you are going. Just try not to break it. If you do, fix it quickly!
|
|
|
|
|
That's a very good idea: Design for change. Although it usually means "fast" isn't exactly as "fast" anymore.
Simply because such design-for-change tends to guide a programmer down a rabbit hole of "what sort of changes can be made". This tends to be one of the culprits in writing zombie code (especially if you organize in OOP structures). But I guess experience would teach you to avoid the pitfalls.
|
|
|
|
|
We got there pragmatically.
We knew we would be updating the software frequently, and in the industry, it was not uncommon to have to schedule an update per client site. We simply did not have the people power to do that.
So, by making the software run an Auto/Optional update (so we could tweak/test things that were ignorable by the users) we could really push updates out. We did 10 updates in a single day in the beginning. I was on site, and every hour we were releasing optional changes as fast as we could.
I don't try to make my OOP stuff that way. I simply try to keep the coupling low enough, that if we have to change, we can. Some changes SUCKED (I will be honest). When we went from Grids that were single select to multi-select. We had to refactor a LOT of code. And worse, it confused new users a lot, so it became a MODE you turn on. Ugghhh. But it worked. New users were happy and learned quickly, and power users could turn on multi-select, select 30-100 records and click Print File Label. And get the file Labels (Printed in the order they were on the screen), as opposed to 30-100 clicks of the Print File Label button.
More like: Assume changes are going to come down the pipe. Where do you want to spend your time. Helping people install the new software, or getting more changes made? Find your pain, and eliminate it.
Thanks!!!
|
|
|
|
|
TheOnlyRealTodd wrote: Is this realistic or is coding not like that and should I just go for it?
How do you think all those people who know the "right" way to do things from experience, got that experience?
Just go for it. You'll learn a lot along the way, and if you manage to architect it right from the beginning, then you'll find it easy to upgrade parts as you go along. If you botch the design part and make it hard to upgrade parts, well, you'll learn how to do that better too, and worst case, you'll have a running product that's a pain to maintain, just like so many other running products 
If you're still concerned, write a throwaway proof of concept. Feel free to take shortcuts that you'd never do for production code on the parts you already feel you know how to architect well because, after all, you're going to throw away the bad bits anyway. Copy-paste the good bits (possibly with some modification) to the real code when you write it.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
What I did(still do), I read other programmers code, I send my code to friends that are more experienced than me and tell them to judge me hard! Trust me it helps.
|
|
|
|
|
Seconding this point... but to one of the original concerns, if you are afraid to write, it's hard to have someone review it to give you that advice...
Additionally, be objective with the response you get. When you create something, there's a tendency to fall in love with it. Be prepared to throw something you wrote out and start over.
"Those who would give up essential liberty to purchase a little temporary
safety deserve neither liberty nor safety. "
-- Benjamin Franklin, 1759
|
|
|
|
|
I used to have same problem (fear of 'doing it wrong'), but after getting a look at some 'professional' code, and working with a few third party APIs, I quickly began to realise that most 'programmers' have very little, if any, idea what they are doing either.
The best advice I can give is just give it try, get something (seriously anything) working, and don't be afraid to throw it all out and start again. You will start to understand the problem, and your tools, much better each time, and once you have something that is 'good enough' you can go from there.
|
|
|
|
|
Why?[^]
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
Perhaps Jesus isn't his friend after all, but has poor aim.
|
|
|
|
|
Mother nature is sitting somewhere going "damn missed by that much".
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
And he's not even playing Pokemon GO 
|
|
|
|
|
I plug in the charger.
The LED turns solid red.
I Check "Settings" and the Android reports "Battery 56%, Charging"
Wait a few minutes.
LED changes to Blinking Red.
I check "Settings" again and the Android reports "Battery 57% Not Charging"
I go across the room. I turn the light switch (which controls that AC outlet) off and on.
LED returns to solid red.
Android reports "charging" again.
A few minutes later, the process repeats.
Anybody ever fix this same problem on your Android phone ?
The model is the Sharp Aquos Crystal. Best I can tell, Sprint no longer sells it, and I wonder if anybody does.
|
|
|
|
|
Replace the socket being used? It seems like hardware issue, consider replacing or trying out a different charger, to see if that works.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
Hope I'm not totally screwed. Just made a date with the store for a repair visit.
Not looking forward to that.
|
|
|
|
|
Maybe replace the battery if it's more than 2+ years old?
/ravi
|
|
|
|
|
Thanks for the idea.
These phones are manufactured so that you can't replace the battery.
When I bought it, I didn't think to ask about that.
A year later, I see that this is "Rated 2.4 out of 5 by 530 reviewers".
Honestly, aside from this battery problem, I like the phone.
|
|
|
|
|
C-P-User-3 wrote: These phones are manufactured so that you can't replace the battery.
That's what they'd like you to think. See this[^] link.
/ravi
|
|
|
|
|
ifixit.com my first stop for questions like this and tools!
|
|
|
|
|
Hmmmmmm,
estimate: 15 - 35 minutes Difficulty: Difficult
Despite the difficulty, thank you, for that link.
|
|
|
|
|
Look for a cell phone battery replacement service in your area - they'll probably charge you $20-$40 (plus the cost of the new battery) if you prefer not to do it yourself.
/ravi
|
|
|
|
|
I've had charging issues due to subpar USB cables.
Have you tried a different cable?
|
|
|
|
|
Yes, I purchased a brand new cable, which worked for a day or two.
After that, the problem resumed.
Went to the Sprint store this weekend, and left it with the technician for a few hours.
He called and told me that phone charged, so I brought him both of my cables and he examined them.
He gave me a third cable. The protruding piece of metal was different by a millimeter or two.
(I wish I had eyes that good.)
The phone charged last night.
Looking okay for the moment.
|
|
|
|
|
I had similar charging issues with my HTC Android phone. It was a bad USB charging cable.
Cheers,
विक्रम
"We have already been through this, I am not going to repeat myself." - fat_boy, in a global warming thread 
|
|
|
|
|
I was really surprised by two things...
- That my second USB cable started acting up very soon after purchase
- That the act of flipping the switch on the other side of the wall would fix the problem for ten minutes (where "ten" is my best guess) I would not physically touch the phone, cable, or current converter. Two seconds without electric power was enough to alert the phone to start charging when I flipped the switch to "on", after which, he stopped charging again.
Duh.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
