|
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
|
As we all learnt from watching Karate Kid, it's a simple case of Wax On / Wax Off. Everything you do [think of it as Ying] has an effect [the Yang] that is rarely what we want [Tong Tiddlie I Poe].
|
|
|
|
|
Nagy Vilmos wrote: Wax Off.
Fnarrr fnarr.
Alberto Brandolini: The amount of energy necessary to refute bullshit is an order of magnitude bigger than to produce it.
|
|
|
|
|
Sidharth R wrote: Can i any help me to know how to be a good developer ?
By using fewer smileys and less punctuation, you may not improve your development skills, but you will appear to others to be less of a 14 year-old and possibly be taken more seriously.
Sidharth R wrote: can anyone tell me about the latest technology in it
Microsoft can ... head over to Microsoft[^] and read.
Sidharth R wrote: how can i improve my Career in software developing
Ask questions. specific ones. If you are working somewhere where you do code reviews, listen to advice, and try to understand why changes are being made. If not, learn from other people's code. If you don't understand it, ask. don't be embarrassed if you don't know something, or aren't sure of the best way to do something. Most developers will be pleased to offer their advice (but try to make sure you're asking the right sort of developer!)
PooperPig - Coming Soon
|
|
|
|
|
_Maxxx_ wrote: try to make sure you're asking the right sort of developer!
And therein lies the problem: You don't generally know which sort you are asking until it's too late! 
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
OriginalGriff wrote: You don't generally know which sort you are asking until it's too late!
You're asking the right sort of developer if the answer they give is "let's talk about it over a pint"
PooperPig - Coming Soon
|
|
|
|
|
Software Development means solving a problem by using languages/tools/technology not learning something. Learn the languages/tools/technology if you need to solve those problem.
Have a nice career ahead!
___ ___ ___
|__ |_| |\ | | |_| \ /
__| | | | \| |__| | | /
|
|
|
|
|
Sanjay K. Gupta wrote: Software Development means solving a problem by using languages/tools/technology not learning something. Learn the languages/tools/technology if you need to solve those problem.
I'd have to disagree with that.
Software development is a process, a way of thinking that is implemented in languages, using tools and technologies. To a huge extent, the languages/tools/technology is irrelevant and can easily be replaced.
You can be as proficient as possible in using the tools (such as VS, SSMS, et al.) but be incapable of producing good software unless you have the thinking part down pat.
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Sidharth R wrote: how can i improve my Career in software developing ?
Find a challenging project that is beyond your current competence, stick with it and don't give up when things get tough.
Use every resource you can - books, google and CodeProject.
Implement the project and write an article on it for CoceProject.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
GuyThiebaut wrote: Implement the project and write an article on it for CoceProject.
A quick look at Wiki[^]...
They have a CocaineProject now? 
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
 
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Somebody, and I don't remember who, said that 'the definition of success is when you don't know whether you are working or playing anymore'.
As a newbie programmer, you will likely be confronted with tasks, and languages, that you don't know about. At this stage you are working for 'them'.
You should, in your own time, choose a language and play. A rewarding choice for this is Python if you are new. You should nurture your skills and enjoyment, and take the lessons back to work.
Eventually, there should be no difference between your playing and your working, except that at work somebody is telling you things and paying you.
I am about to start learning Lua at home, because I only heard of it last week.
|
|
|
|
|
LOL that's right, start them in Python and let them get spoiled by ease of use and an interpreter...wait 'til they get a load of C#
"Seize the day" - Horace
"It's not what he doesn't know that scares me; it's what he knows for sure that just ain't so!" - Will Rogers, said by him about Herbert Hoover
|
|
|
|
|
As my brother says, the "secret" of getting good at anything is Time on Task.
I agree with the observation that it takes 10,000 hours--five to seven years of full time work--to become expert as something, which is why I don't trust most developers who know "every" language and technology.
BTW, the single biggest problem I see with developers is that they don't understand--truly understand--what the code is really doing. One way to help that is to step through the code with a debugger and really pay attention to what's going on.
|
|
|
|
|
No, you are not....yet! Have fun anyway.
|
|
|
|
|
You need three most important things to be software developer any company will try to hold after you've worked there for a while.
1. Errors (the most important) - Usual user does not handle errors, it just says it doesn't work. You should be able to understand the error, find its source, reason and the idea what developer written that code were trying to do, especially when you are working on someone else code (even from different company). Keeping developer's idea, keep the software architecture unchanged, making handling error easier, faster and cheaper for your boss.
2. Theory - yeah, theory. That stuff you learn at university. Most of us say it doesn't help. Computer theory is just a bunch of rules trying to say what can be done and cannot be done in computers. Also complexity analysis trying to say what is the best way (faster or with minimal memory usage, etc.) to do something. The theory is trying to be general. That means if theory says something is better than other, no language will make it different. Due to generality theory usually says so less. But understanding the language theory will make you able to learn any language practically in a matter of days (or hours).
3. Intuition - a lot of people develop, but only few have intuition. Thrust your intuition. If you feel something is wrong and you should not write it that way - most probably it is true. Intuition is part of the subconsciousness and you can't access subconscious. That doesn't mean subconscious can access your consciousness, meaning your intuition is as smart as you are (it knows everything you know). If you feel something is wrong, then probably your subconsciousness noted a problem, which you didn't see, yet. How to gain intuition? Code. Code at work, code at home, code on holidays. Never stop coding. Doing to so often will make coding a reflex - something you can do, while do other stuff. And reflexes are part of your subconsciousness. Every time you code is just a training for the brain.
|
|
|
|
|
|
I don't know if anyone's asked you this but what kind of applications will you be developing (e.g. web, desktop, server , mobile, all/none of the above...)?
modified 31-Aug-21 21:01pm.
|
|
|
|
|
Um, avoid sounding like a parody?
|
|
|
|
|
find a good developer within your company and hitch your wagon to him. When I started way back in the 70's I spent years teaching myself and going on the odd course, but it was only when I started doing it full time for a living (and had a good boss) that I realised how little I actually knew and what good coding was. GL
|
|
|
|
|
I would suggest three things:
1) Learn SOLID design principles
2) Software design patterns
3) Read! (Some suggestions)
- Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin
- The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin
- Agile Principles, Patterns, and Practices in C# by Robert C. Martin
Eric
|
|
|
|
|
You'll need to look this up, but as a start when another developer ask you "What is the airspeed velocity of a fully laden swallow?", you should almost instinctively and immediately respond with the correct answer. Also you should at least one reference in comments in your code:"A moose once bit my sister" (from the same movie).
I usually mention this once during interviews... If there is at least a glint of recognition, You're hired 
Mike
|
|
|
|
|
Only rule I know is Don't be a dick and you'll do fine!
|
|
|
|
|
Learn visual basic 6.0 and C++
Both these technologies are the basis for the .net framework.
Also learn the dot net framework 1.1 - this is the only version that all the code won't change, and every part of it is still there - everything built on top of this is subject to change and continues to change.
Understanding those three technologies would gave you an edge above the rest.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
