|
“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.
|
|
|
|
|
To be a good developer:
1. Understand that you will never stop learning. Everything changes rapidly and it is extremly easy to get left behind.
2. But... The basics of good programming don't change. Whatever problem you are given has to be broken down to managble segments and solved piece by piece. Languages are not overly important, most have very similar constructs and features and programming skills should be lanugage agnostic to a large degree.
3. Test. Test. Test. Very rarely will you write a piece of code that actually works correctly under all condtions in one try. Assume that whatever you write will have bugs in it, so exercise it and test the boundaries. Also remember that you never trust that the input (at any level) is what you expect, check and verify it.
4. Listen.
To the people around you that have experience, their war stories can help you avoid making similar errors. In time you will have your own.
To your customers. For most programming jobs, you will be creating programs to supporting your employer. You will need to learn enough of the details of how the business operates that you can understand and correctly interpret the requests being made for computerized solutions. This means becoming comfortable with the terminology, processes etc. that allow the business to operate. Many of the people making such requests are not computer literate and will make assumptions on how or what the computer will do that are not in fact possible. Your job is to take the initial request and determine exactly what is desired, then get the computer to do it, or, show why the request is not solvable (logical inconsistency, invalid assumptions, etc.) and work to redefine
5. Make sure your logic is complete. For instance: When you write an if statement, make sure you consider the else portion as well. I can't tell you how many times I've seen issues where the else was missing and something unexpected occured when the if condtion evaluated fale. If no action is needed for the else, put in a comment to that effect, it will at least show that you considered that path. For loops, (depending on the type of loop construct), you consider the case where the loop never executes because the termination condition was reached before entry to the loop.
6. Use the people around you. If you are stuck with an issue, try to explain it to a co-worker, sometimes they can assist, but more often, having to explain it will allow you to solve it because you have to think it through from the perspective a someone seeing the issue for the first time.
7. Google, Bing, CodeProject, etc. are your friends. It's truly amazing what you can find with a few simple searches. Just remember, not everyone that posts is really an expert (except in thier mind), so read multiple answers and the comments about the answers, you can ususally see what approaches work and what don't.
|
|
|
|
|
|
A good developer have good analytics skills, it serves to deal with the, often vague, requirements of the end user, as well when you're dealing with the spaghetti code someone wrote 10 years ago, this is the most important skill; technologies, come and go, so I recommend you to stick with whatever they use, but also look for what technologies appear in the "news".
PS: Perhaps async programming and lambdas is the latest and the greatest in the .NET world, so it's a good place to start.
|
|
|
|
|
Reading, reading and reading.
1. Try to learn best practices in software development by reading materials such as .NET naming convention, C# syntax, Object Oriented Programming concepts, etc.
2. Try not to memorize the framework,but rather try to understand. The framework might be different in your next carrier.
3. Try to learn from people who has more experience, because this is the fastest way to learn. For better understanding - listen and experiment with the coding.
4. Do not right any complicated code during your first year.
5. Subscribe for computer news, MSDN magazine, etc.
In my opinion here are interesting articles to read
Link1
Link2
Good luck.
SergoT
|
|
|
|
|
via eMail:
Dear Customer,
Your Apple ID has been temporarily Locked!
We detect unauthorized Login Attempts to you Apple ID from other Ip Adress.
Please re-confirm your identity today or your account will be Locked sur to concerns we have for the safety and intergrity of the Apple community.
To re-confirm your Apple ID , We recommend that you go to [dodgy .ru link]
So, I can't access the Apple Store, not really unexpected as I've never owned an Apply product, though I wanted a ][e, and never registered. 
|
|
|
|
|
If you send me 100 bucks, I can unlock it for you again...
Anything that is unrelated to elephants is irrelephant Anonymous ----- The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944 ----- I'd just like a chance to prove that money can't make me happy. Me, all the time
|
|
|
|
|
For his convenience you should have offered him to give you access to his paypal account or his credit card information, so you can send the 100 bucks to your account yourself. That way, it's a worry-free transaction, he has his account unlocked and the payment is taken care of as well.
I won’t not use no double negatives.
|
|
|
|
|
Nagy Vilmos wrote: I've never owned an Apply product
This list probably includes every major company in the western world, the current one turning up is Amazon and Wells fargo, they really think we are idiots!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Nagy Vilmos wrote: I've never owned an Apply product Anyone who's never owned a Beatles album isn't worth talking to.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
So, in my old house you could get a small 'shock', although that's probably a strong word for it from touching the metal light switches. It would be most noticeable if you gently stroked the switch (there are worse perversions) as a sort of fuzziness in your fingertips. One of those electrical tester screwdrivers lights up when you touch it.
Said light switches were earthed, but I guess it means the earth wire wasn't actually attached to the Earth and was floating.
My questions is where the electricity came from. I was thinking a short via a very high resistance somewhere but then I actually wondered whether it could be caused by induction, the wiring in the house acting as a very spread-out transformer as such.
Any thoughts from the electrically minded?
Regards,
Rob Philpott.
|
|
|
|
|
Get an electrician in.
Quickly.
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 – ∞)
|
|
|
|
|