From mind to manufacture

closed account (G30oGNh0)
How does one get information from their mind, into the real world? Is there a generic way of doing this?

Both with programming and music, for years I have not found a way to put my idea's unto pc / guitar. I can get some, but never the finished product. Anyone with experience like to share their steps?

Also, general intellectual expansion thread.
closed account (1yR4jE8b)
Dedication mostly, too many people hit a roadblock and just give up. The people that succeed are the ones that just see that as another challenge that needs to be overcome. Not getting bogged down by your failures is another one; how do you expect to succeed if you can't get over that you've failed before? You need to walk before you run, and most people fall over and over when learning how to walk.

Also not getting hung up on minor details helps quite a bit. Sure, all us hobbyists want to have the "cleanest and most efficient code ever!", but it's useless if the code doesn't do anything useful. You need to strike a balance between writing elegant code and just getting shit done, and that comes with practice, experience and the occasional ego check.

Ninja Edit:

Also, working with somebody of a slightly higher skill level is also helpful -- as long as they are not a jerk. Working with someone that you are accountable to is a surprisingly strong motivator, and you can learn a lot from the feedback of somebody who has more experience then you. Just gotta try really hard to avoid clashing egos. I find pair programming works very well when you know and get along with the person really well.

https://en.wikipedia.org/wiki/Pair_programming
Last edited on
Do you mean how to literally hook up a brain and transfer data onto a PC? Lol, if you ever figure that out make sure not to tell any of us because that's a lot of money there.
closed account (G30oGNh0)
Thanks for the reply dark, I couldn't agree more with the minor details ( When it comes to coding at least ) I think that's one of my major down falls, I try to get each piece written to the best standard before I move on, making me consume so much time I just inevitably loose interest before I have anything of worth.

I do dedicate myself to coding, I really want to do it, but there is so much I just can't comprehend, somethings that just make no sense to me at all while most say it's easy, I would use the excuse 'I don't have the mind for it' but I know there is no such thing.

Is over-reaching a problem? Although I do like a challenge, I never know when something is too much for me, but if I do something easy I won't learn, where is the middle ground here?
closed account (G30oGNh0)
@Austin,

Oh, I'll make sure to share it all with you! It's about learning not the money :)
closed account (1yR4jE8b)
Over-reaching is definitely a problem. Like I said, you need to walk (and sometimes crawl) before you can run. Young game developers, for example, get way to overambitious with their initial projects (OMG LIKE I WANT TO MAEK A 100% SCIENCE BASED DRAGON MMO). These people doom themselves to fail right from the start, mostly out of ignorance and not really their fault either -- just a lack of experience. Doing thing incrementally is often the best way. Make smaller projects that implement a single simple concepts, then figure out how to get them to work together. You'll also get less overwhelmed, and learn much more in the long wrong.

I try to get each piece written to the best standard before I move on, making me consume so much time I just inevitably loose interest before I have anything of worth.


I find using test-driver development helps quite a bit here, if you can define the problem programatically in code, say an initial small set of 10 unit tests and code to make those tests pass and move on right away you get better results. Things that don't affect whether tests past or not can be generally ignored, and you also get a nice set of tests that help ensure you don't break your code in weird places as your project gets more complicated.
Music is fecking weird and I don't think anyone could possibly begin to describe how things go from their head to music. Programming might be the same...

Certainly with music, I found getting better on my instrument unlocked a great deal of doors and as you get better, they just keep unlocking.

closed account (G30oGNh0)
@Dark

Could you explain a little more with the 'test-driver' paradigm? Maybe with an example? Also would you be willing to be my pair buddy for programming? You won't have a problem with 'ego clashing' with me, I don't have one.

@Mats

Over the years my guitar(ing?) has come leaps and bounds, I can get very technical, I can write riffs, solo's etc, I know my theory and scales, but putting it all into a 4 minute track I just cannot do without it sounding too...robust, pre-made. People like Joe Satch, Mclaughlin can make their music flow just as water, if only there was a simple answer to this!
closed account (1yR4jE8b)
oh, whoops, I meant "Test Driven Development", my bad. Anyway, the basic idea is before you even start writing any of the actual code for the project you write some tests for the code.

I know this sound backwards but bear with me.

Obviously those tests are going to fail right out the gate; but what we do have is a set of requirements that defines how the code should work. So we start coding to start making these tests pass. So if we have a set of 10 tests, we work on making that first test pass. Once that test "turns from red to green", we move on to the next one. Code that doesn't affect whether a test pass or fails gets tossed. Once our first set of tests are all green, we write more tests for new functional requirements, and we repeat the process.

I find writing the tests first give me a firmer idea of what I need to do for a project. Reading old tests and writing new ones also tend to give me bursts of inspiration. It also tends to keep me on track, ("ok, I've got these 3 specs I need to turn green"). The test also help me when refactoring, because I can find if and where I broke something while refactoring relatively quickly. As a project grows in complexity, and different components need to integrate with other components in increasingly complicated ways, the tests also help find places your code might fail that you did not expect.

Also would you be willing to be my pair buddy for programming?


I'd like to, but I can't. Between my full time job, and the startup I'm trying to get off the ground with a few partners (buddy programmers you could call them even), I just don't have the time to pair up with someone else. I'm sure there's someone else on this forum that would love to either have a partner for one of their projects, or join up with you on one of yours.
Could you explain a little more with the 'test-driver' paradigm?


This does an excellent job of getting the idea of test-driven development across:
http://www.slideshare.net/JonJagger/larry-and-jen-do-roman-numerals-in-c
closed account (G30oGNh0)
@Dark

That does make total sense, I'm going to give that a try today!

I understand if you can't, everyone is very busy these days, I'll try and start a thread going where people pair up and start programming together. Due to my severe withdrawal from social life I don't know anyone who likes programming. It would be great if this website had a 'Buddying' system where experienced programmers work with amateurs to get them off the ground, then as they go through the ranks they start working with more experienced people learning more etc. Food for thought I reckon.

@cire

Thanks for the slideshow! Those kids have a better programming grasp then I do :) I fully understand it now thank you!

PS: I apologize for my absence, I had to sleep over my sisters last night to 'Dog sit'
Topic archived. No new replies allowed.