I made a conscious choice to write 'non work' code every day. It's now a habit (thanks largely to Github's contributions graph... I've got to get a little green square every day!). Sometimes it's just 5 minutes to refactor something or update a README, sometimes it's 5 hours to work on a project, but the result is the same - I spend more time writing code. This has introduced me to frameworks, libraries, patterns and algorithms that I wouldn't have been exposed to otherwise, and it's definitely making me a better developer.
A friend of mine in a similar situation is making a game with his kid - he writes code while his child is drawing sprites. They collaborate on the game mechanics, testing, etc. That works for him and (he says) it's quality time that's loads of fun. Maybe you could include your kids?
Not the OP. When I started out I took a conscious decision to stay away from IDE'S.
an IDE adds complexity when the main goal should be to learn to program. An IDE has a bunch of features you need to learn and understand when learning to program by itself is hard enough.
Python is, possibly because it originated as a scripting language, very amenable to non-IDE development. In general, my experience is that the less statically-typed a language is, the less essential IDEs are.
That is a language that is perfectly fine to start without an IDE but for example Java and C# are pretty much designed to use with an IDE, at least when you are building something that is non trivial.
You don't have to use all the power but letting for example Visual Studio handle the project references and build for a .NET project will allow a beginner to focus on coding. Not to mention all the tutorials will assume they use Visual Studio.
I had a feeling it would be something along those lines. When I began I actually started with Java and later dabbled with C# but didn't get far with either one of those. I had no idea what I was doing. I probably still don't ¯\_(ツ)_/¯
I finally settled on Python after jumping around quite a bit and am still learning.
They introduce unnecessary complexity and tend to make users too dependent on them, while hiding actual functionality behind colorful buttons. There's a reason most productivity-focused programs are terminal or text-mode programs.
An IDE-dependent toolchain is a sure sign of an immature project and, likely, rookie developers.
If you just starting learning programming, I totally agree with you. I always tell that to everyone wanting to learn programming.
But, if you already good enough in programming or a professional one, you should use anything useful for your productivity, including IDE.
1. Get a visual prototype going as early as possible - even if its screen mockups. Your interpretation of what the client wants and what they tell you they want are often completely different, and many times they don't really know at all.
Once they can see something, then requirements get a lot better.
2. Once you have a better idea on what you will be building, work out in your head how you will build it.
Think about all the parts and do the bits that you haven't done before, or don't know how to do and build them FIRST.
This will avoid showstoppers down the road - you may not be experienced enough to know if it's something you can't / shouldn't do, or if extra help / libraries are needed to complete the job.
So once you have a clear idea on what you are building, and have done test functions to do the hard bits - then it's time to turn on the music and build the rest.
Read other people's working code. Figure out what they're doing and why and why you like or dislike it. Add their unique qualities to your own repertoire.
26 comments
[ 3.3 ms ] story [ 66.5 ms ] thread2: Keep your toolchain and build process independent from the operating system and editors.
3: Don't use IDEs.
4: Have a one command automated build and run as soon as you write a basic skeleton of your project.
an IDE adds complexity when the main goal should be to learn to program. An IDE has a bunch of features you need to learn and understand when learning to program by itself is hard enough.
You don't have to use all the power but letting for example Visual Studio handle the project references and build for a .NET project will allow a beginner to focus on coding. Not to mention all the tutorials will assume they use Visual Studio.
I finally settled on Python after jumping around quite a bit and am still learning.
They introduce unnecessary complexity and tend to make users too dependent on them, while hiding actual functionality behind colorful buttons. There's a reason most productivity-focused programs are terminal or text-mode programs.
An IDE-dependent toolchain is a sure sign of an immature project and, likely, rookie developers.
1. Get a visual prototype going as early as possible - even if its screen mockups. Your interpretation of what the client wants and what they tell you they want are often completely different, and many times they don't really know at all. Once they can see something, then requirements get a lot better.
2. Once you have a better idea on what you will be building, work out in your head how you will build it. Think about all the parts and do the bits that you haven't done before, or don't know how to do and build them FIRST. This will avoid showstoppers down the road - you may not be experienced enough to know if it's something you can't / shouldn't do, or if extra help / libraries are needed to complete the job.
So once you have a clear idea on what you are building, and have done test functions to do the hard bits - then it's time to turn on the music and build the rest.