4 Replies - 673 Views - Last Post: 16 January 2013 - 03:45 PM

#1 kevin_mchugh  Icon User is offline

  • D.I.C Head

Reputation: 11
  • View blog
  • Posts: 70
  • Joined: 08-April 09

The next step

Posted 16 January 2013 - 08:33 AM

This may sound like a strange questions and I am not sure its in the right place (And apologies to moderators in advance if it is!) but.....

How do you take the next step with your coding? At the moment I understand the Fundamentals of OO Programing etc. and can read and understand the majority of the code I find online but when I read through tutorials etc I fail to understand how they come up with "I will start with X class" or "I will use Y pattern". (Although I can implement and understand them well enough!)

I work as a professional "software developer" and I can fix most bugs at 100 yards. I can build small additional pieces to an existing system (Usually based of an existing logic.)

But how do you get to the "This is the problem" and then think up and "Elegant solution". I can refactor code so it runs a little better/looks better but at the end of the day its always "basic".

I keep getting the feeling I am a hacker who got lucky!

Everyone treats me like I should know, that I am MUCH better than I am....but I donít. It's like laughing at a joke that you don't understand.

As I said I hope this makes sense and that someone can't point me in the right direction.

Kevin

P.S I have a first class degree in software engineering and one and a half years of commercial experience.

Is This A Good Question/Topic? 0
  • +

Replies To: The next step

#2 modi123_1  Icon User is offline

  • Suitor #2
  • member icon



Reputation: 9287
  • View blog
  • Posts: 34,811
  • Joined: 12-June 08

Re: The next step

Posted 16 January 2013 - 08:37 AM

Quote

But how do you get to the "This is the problem" and then think up and "Elegant solution". I can refactor code so it runs a little better/looks better but at the end of the day its always "basic".

Read up on general 'software development methodology' and design patterns.. then apply that to projects in the project list. After each do a postmortem; look at what went well.. what went wrong... and what needs to be added. Repeat.
Was This Post Helpful? 2
  • +
  • -

#3 tlhIn`toq  Icon User is offline

  • Please show what you have already tried when asking a question.
  • member icon

Reputation: 5537
  • View blog
  • Posts: 11,868
  • Joined: 02-June 10

Re: The next step

Posted 16 January 2013 - 08:46 AM

Practice... practice... practice...

Recognize that there is a difference between being a 'coder' and a 'software engineer'. Most of that difference is in your mental approach to problem solving. Engineering is as much art and science. Its as much being a detective as a coder.

Practice... practice... practice...

And I mean practice ENGINEERING not just coding. It doesn't matter if the project is a complete clone of some pre-existing program and you're never going to sell it - but design it and build it anyway, start to finish. You need to design something, build it, run into the problems, paint yourself into corners and find your way around it - over and over - to train your brain to see a little further into the future so you start improving your initial designs.

My regular job has me building software with a particular goal and need. If I don't make a point of spending my off time on other projects then I feel my brain getting tunnel-vision. I make a point of finding things to build that are far different from my paid job just to stay well rounded and get my feet wet in areas I wouldn't see on the the job.

Practice...

Practice...

Practice...
Was This Post Helpful? 1
  • +
  • -

#4 jon.kiparsky  Icon User is offline

  • Pancakes!
  • member icon


Reputation: 7807
  • View blog
  • Posts: 13,203
  • Joined: 19-March 11

Re: The next step

Posted 16 January 2013 - 08:51 AM

Design patterns aren't learned by reading. They're just a language for talking about experience in designing. You don't learn them, you discover them. Then, you go and read about them in the GoF book, and you find out that there's a name for them.

If you want to understand design patterns, write programs that are complicated enough to need them. Don't think "what pattern should I apply" think "what does this situation require?" And then build the thing out to completion so you can see all of the effects of your design.

In other words: design is a craft that's learned by repeated application of nose to grindstone. You can read about it, and probably get some good ideas, but the only actual learning you do is when you're actually implementing a design that you've developed - and debugging it, and modifying it, and hating yourself for designing it wrong the first time.
Was This Post Helpful? 2
  • +
  • -

#5 Lemur  Icon User is offline

  • Pragmatism over Dogma
  • member icon


Reputation: 1372
  • View blog
  • Posts: 3,472
  • Joined: 28-November 09

Re: The next step

Posted 16 January 2013 - 03:45 PM

What's the first step you take when you're handed a problem? If your answer is an IDE, or what language, or anything to do with programming itself you're not thinking in the right context. Focus more on the what than the how. You already know the how, that's not an issue if you're already a bit experienced.

Define the problem, find out what it is in its entirety. Set up road maps, do some preliminary planning and analysis of the problem itself and make sure it actually is a problem to start with. You are not allowed to think of a lick of code or technical solutions to any of it until you complete the following:

> Preliminary Planning
> Analysis of the Problem in its entirety
> Preliminary Design (Brainstorming ideas, and charting everything such as database layouts.)

NOW you start thinking about code with detailing the preliminary design, and working on implementation. Planning. Plan plan plan plan plan. I can't say that enough.

If you don't have a few whiteboards full of charts, diagrams, and analysis you're not up to par on planning. Even then you're probably playing on the light side.

"Give me six hours to chop down a tree and I will spend the first four sharpening the axe." - Abraham Lincoln

One hour of planning is worth five in hacking and coding. The difference between coding and engineering is that a coder knows all the pieces and parts, while the engineer knows how to use them correctly to solve the problem.

TL;DR: Focus on what the problem is, rather than how it can be solved.
Was This Post Helpful? 2
  • +
  • -

Page 1 of 1