Slashdot Mirror
Ask Slashdot: What Makes a Great Software Developer?
Nerval's Lobster writes: What does it take to become a great — or even just a good — software developer? According to developer Michael O. Church's posting on Quora (later posted on LifeHacker), it's a long list: great developers are unafraid to learn on the job, manage their careers aggressively, know the politics of software development (which he refers to as 'CS666'), avoid long days when feasible, and can tell fads from technologies that actually endure... and those are just a few of his points. Over at Salsita Software's corporate blog, meanwhile, CEO and founder Matthew Gertner boils it all down to a single point: experienced programmers and developers know when to slow down. What do you think separates the great developers from the not-so-fantastic ones?
Here's an alternate link for the first article.
Or better yet, skip it. Usual shitty dice.com summary article.
The linked lifehacker article seems pretty good and I largely agree with it. Couldn't make it through the second one.
Two things I would add from my personal arsenal:
- Try to kick ass at least once a week. This sounds weird, but it's worked very well from me. In the perfect world we would kick ass every day, but I think realistically we (or at least I) would quickly burn out. So instead I try to just randomly pick a day where I come in with the mindset that I'm going to just fucking own whatever I'm working on. The day is random and sometimes I skip a week, but I usually manage, and while you would think inconsistent performance would stand out, I've found (at least where I work) that it doesn't, and people tend to remember the kick ass days rather than the average days.
- Dive into the stuff that others avoid / are scared of / don't like doing for various reasons. I'm not saying take the shit jobs, but usually there are tasks programmers hate because they involve working with hardware, dealing with clients, travelling, or doing something out of their comfort zone. Become the <whatever> guy.
Beer makes everything better ;)
The best "lone wolf" developers probably use something like Lisp and a high amount of math-like abstraction to crank out vast amounts of features in a short time.
However, a good team programmer knows how OTHER typical programmers think and read code, and writes code that is easy for them to navigate, digest, and change. Team programming is more like authoring a good technical manual, not clever gee-whiz tricks.
Table-ized A.I.
First level is to be able to get the computer to do what you want. If you can do that, you have a career as a programmer.
Most people don't make it that far, so it's something. The next level is whether you can write readable code. A lot of programmers never learn to write readable code, but a good number of them do.
The next step is writing flexible software. Some programmers stuff everything into design patterns and think they made it flexible, but they're wrong. Other programmers try to make everything generic thinking it's flexible, but they're wrong (also, their code is probably hard to read). But writing code where small changes take little effort, and bigger changes take more effort......that is a rare skill indeed.
There are other ways of looking at it, but that's one way.
"First they came for the slanderers and i said nothing."
American first. British second. Canadian third. South African fourth, but only because it sounds cool. Austrilian and the NZ not wanted here! Hong Kong as a last choice - every other english-speaker dead or dying.
Great developers use Pascal. ;-)
before computers, they might have been an engineer, as in railroad, really. so, how can humans be "made" into a developer? same as just about anything else. they make themselves.
It's not that great software developers never make mistakes, it's just that by knowing they can and will happen to anyone, they can try to catch them early.
It's the people who think the code they write is flawless that tend to have the most problematic code.
You are a builder first and a researcher second. It is the art of being a construction worker, architect and civil engineer all at once - you need to know when enough is enough.
A really good developer is someone who can show 5 more people how to do the same great things.
To be a great programmer (or even just a good one), you need to never stop learning. Always be learning something. Many times in my life I have learned something on my own, only to be able to apply is a totally different situation later in life.
Great programmer are insanely curious. They want to know the how things work, why one solution is better than another, always improving. That is the key, always be improving your craft, and your knowledge.
Suppose I make a 2x2 Rubik Cube. You and 100 others say we must extend this to 3x3... ...And somebody does. Hurrah!
Concepts that catch the imagination come first. Then comes the sense to build a foundation or the tools or the clear ethos or the luck to know a few bods who will play as a team following your clear lead. (They may be ancillary skills to big chief um he programmer, but everyone sees the purpose of the device.)
You WILL make mistakes and introduce bugs when coding. A great developer knows this.
Ask anyone you think is a great developer, "What do you do to help prevent or detect the mistakes you make?"
can tell fads from technologies that actually endure
And are therefore defined in hindsight.
Critical thinking, not buying anything some software vendor is willing to sell you, is one thing, and betting on the right horse every time is quite another.
At some point, you can't miss the latter by being conservative and only adopting "new" technologies when they're already mature (now, if you had some sort of almanac...). Also to note, "better" does not always mean "successful".
I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
The ability and desire to distill/abstract/acquire and then apply knowledge. There's nothing more to it.
I suck at this programming stuff.
p
Anyone willing to work under H1B conditions and for H1B pay
Copious amounts of hubris.
(see Lennart Poettering)
Whether or not it is called "Software Development" or "Software Engineering" or "Coding" or whatever the newest trendy iteration, they all boil down to identifying the need and/or problem and then SOLVE IT
From the primitive but extra-ordinarily crucial computer systems that ran the Apollo space program to Lotus 1-2-3 to Linux, all they did was the same --- they identified what is needed and then providing solution to get the problems licked
Muchas Gracias, Señor Edward Snowden !
But, in my experience most people with prestigious degrees or degrees beyond a bachelors degree are the shittiest programmers. They know all sorts of terminology and can recite all sorts of definitions and methodologies but when it comes to hands on coding they literally suck ass.
I think one of the most valuable abilities for a good programmer is to be a good listener. A big part of that is also being able to ask good questions. You need to be able to fully understand the problem to be able to develop the right solution -- remember, the solution that customer actually needs is not always the one they think they want. Also, being able to listen also means you will be better able to learn new skills.
I believe in de-evolution. God made the world perfect, man fell, and its been going downhill ever since!
I started a software company back in 1999; we're still around and up to 10 employees, so I have had some moderate success in the software business.
I think the LifeHacker link makes a lot of good points. I especially agree with limiting overtime. I *never* ask my developers to work overtime. Just never. Because I don't set release dates. When someone asks when the next release will be, I say "when it's ready" and I mean it. It's far more important to get it right than to get it out "on time", whatever that is.
I would add that to be a great software developer, you need a lot of discipline. You need to write your unit and regression tests even if you don't feel like it and even if you'd rather be moving on to the next cool feature. You need to write your documentation clearly and comprehensively. You need to have your code reviewed; even the best programmer can benefit from suggestions that improve code clarity.
You need to listen to your customers. You can write the greatest software in the world, but if it doesn't do what your clients want, that's not much use. But you also need to have enough judgement to know when your customers are asking for something ridiculous and you need to have the communication skills necessary to explain to them why what they think they want isn't what they really want.
You also have to be passionate. If you went into computer science because you thought you'd get a secure job, but never particularly liked computers and didn't do programming on your own time, forget it... you won't be a great software developer.
Beer and lots of offshore help! :)
The more you rely on offshore help to solve the problems on hand the more beer you gonna find yourself gulping down
Trust me on that !
Muchas Gracias, Señor Edward Snowden !
You have the 'knows how to work efficiently to get the project done as quickly as possible'.
And then you have the 'knows that they'll have to maintain it, and will work to make sure to minimize shortcuts, or document every od trick they used, so that two years later they'll be able to modify it when some new requirement comes along'.
I actually enjoyed doing the first type of programming. These days I see paralized and might be over-designing things because of times that I've gotten stung by not being type #2. (both my own code and other people's)
Build it, and they will come^Hplain.
there's nothing like a real life emergency in programming but business culture is "get this done yesterday." no one can do that. but some programmers are very fragile and can only function according to one set of requirements/ work environment/ speed, and if you mess with that they get angry/ stressed/ tune out/ burnt out. while the "rock stars" can react to sudden and dramatic changes of requirement and need and crank out the changes relatively adroitly (not necessarily quickly). a sort of suppleness of mind and eerie lack of stress that's more about personality than training. and i say personality, and not training, because their code is a reflection of their personality: you can throw a curve ball at it from any direction and it can adapt without falling to pieces when "little" things (it's never little) change
your code is a reflection of how your mind works. which is your personality. and certain chilly stress proof people can generate flexible durable code that is almost like the redundancy and flexibility of logistics in war
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
It's like porn; it's difficult to describe, but you'll know it when you see it.
People without good taste (regarding to the code) will never become great software developers.
Cheetos and Fritos.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
You know, the kind that doesn't fire you after the first mistake, the kind that provides guidance, training, education, and invests in its workers.
(AAHHHHHH HAHAHAHAHAHAHAHAHHHA!!! BAAAAAAAAAAAAAAAAHH HAHAHAHAHHAHAHAAHAAA!!!!!)
You know, an employer that's willing to take the same risk in hiring you, that you took in paying for that four-year degree?
Oh sorry, "risk" is for *you*, *they* get the profit!
Mostly random stuff.
Coders are the modern day version of the secretary. A great software developer is someone that gets however many chumps that it takes to get the job done, to do it for her. If you're writing code, you're not a great developer.
It's simple, you have to LOVE development. You have to love and desire the creative act...a deep desire to build something that is useful to other people, In the end, it's about service. Most important you have to have a deep desire for revenge against all those who said you were an idiot when you were 10 years old.
To be a great software developer, you need to write great software. Any great software requires a lot more forethought than just coding.
Upfront design is the key to flexible and maintainable software. Peer reviewed, simplified, unoptimized design gives you a great base to start writing great code. It is akin to listening to a shakespeare play before writing one (as opposed to just winging it as you move along) .
What do you think separates the great developers from the not-so-fantastic ones?
A crowbar?
Having built a long-term development team from scratch, and having screened a lot of consulting software engineers, I eventually came up with an acronym that describes what I look for: Talent, Experience, Professionalism, Education, Skill (TEPES). I wrote a post on the subject back in 2008 -- you can read it here. ..bruce..
Bruce F. Webster (brucefwebster.com)
Hint - if you think that you're the best coder in the world, and that everyone around you is only outputting a bunch of shitty buggy crap, it's probably time for you to do a bunch of introspection.
It's a well known phenomenon that experts will tend to play down how good they are (because they realise what they don't know), while non-experts will tend to play up how good they are. The fact that you're claiming to be god's gift to man kind, and that everyone else seems to be doing something different is a good indication that you may well be in the latter category.
Don't get me wrong - you may actually be god's gift to man kind, and/or you may be amongst a bunch of incompetent monkeys, but that's not the likely scenario.
Codefusious say man who misread x86 page size, high on pot.
Mod me down, my New Earth Global Warmingist friends!
1. Imagination
2. Dedication
3. Fascination
Note that Education was not in there! I took a few computer courses in college (engineering school), including BASIC, Fortran, and such, but they were a waste of time. I got more from my philosophy course in formal (Boolean) logic than anything else. I started with writing an accounting package for a commercial bakery in the Silicon Valley in 1982-83 and now am a technical architect for a multi-billion $$ company. My previous position was senior systems engineer for Nokia Mobile Phones. I have no degree, yet I am a senior member of the IEEE and director (and previous chairman) of an IEEE affinity group. These are the programming languages that over my career I have used to develop commercially viable systems:
1. dBase II and dBase III (I was a beta tester for dBase III) ...
2. MS/PC BASIC, Business BASIC
3. C
4. C++
5. Cobol
6. DIBOL
7. Java
8. x86 assembler
9. Javascript
10. PHP (I wrote a cell phone emulator in that)
11. PL/SQL
12. Transact-SQL
13. ADA (PL/SQL is a subset/superset of ADA)
14. More, and more, and more... PL/M, Smalltalk, Lisp, Prolog, Pascal, Snobol, CSH, KSH, Bash, Perl, Python,
These days, most of my coding is in Javascript. My preferred programming languages are C and C++.
Final note. If you are using PHP to build web services, treat it as a formal object-oriented language. DO NOT mix PHP and HTML or Javascript! Trust me, your web sites will be more secure, run faster, and be simpler to debug.
Yep, I've never met a really good programmer who didn't use every tool he could exploit to find his bugs. Every one of them that I ever met had a strong leaning towards strongly typed languages, because they could exploit the type checker to find their bugs. They had a strong leaning towards testing, because they could exploit it to find their bugs. They had a strong leaning towards running profiling tools for memory, leaks, performance etc because they could exploit them to show were their code was really bad.
As far as I'm concerned - lesson 1 is to use every tool you possibly can to prop yourself up - get the computer to make you into a good programmer.
It depends what you need the developer for.
But first let me get this out of the way: YOU WILL NEVER BE A GOOD PERSON BECAUSE YOU ARE A GOOD SOFTWARE DEVELOPER. This is not as bad as it sounds. Since good development cannot make you a good person bad development cannot make you a bad person either. I felt it necessary to state this because there is a stupidity built into the question "what makes a great software developer?" If one is asking this to find out if he is a great developer, it's better not to go there at all.
I think the most valuable developers today are developers that have effective testing skills. They have internalized that no matter how good they are they are never good enough to shrink the bug list unless they write tests. An organization filled with such developers is well off.
We judge ourselves by our intentions while we judge others by their actions. Same goes for programming. We judge ourselves by what we believe we're capable of while we judge others by what they actually produce.
...Great programmers:
1) Provide reliable estimates that aren't inflated.
2) Meet aggressive deadlines, even when unplanned work was added to the project during development.
3) Take responsibility for their bugs and get them fixed, on deadline.
4) Don't take time off during crunch time.
5) Are willing to help when called to troubleshoot a surprising client issue on a weekend.
6) Are humble enough to be content with an average salary, rather than always demanding raises to be paid at the top of the industry.
Get the fucking job done on time, and do it correctly. Everything else is ego jackoff bullshit.
IMHO, a good developer needa to CARE about what he/she is writing. Here are some points I've gathered from two decades of development work:
Care about the code
The quality of the code, efficiency, consistency are all key. Internal documentation is very important. Even if you don't think anyone will *ever* look at that code again, guess again. Someone will probably end up going back over it in the future to fix a bug or add a feature -- often times that is YOU, the one who wrote it. So leave enough comments behind to tell the next guy (or you when you've long forgotten that code) what in the world you were thinking. I've known way too many developers that simply say "yes sir" to their boss and crank out the code as fast as possible. They don't bother to think for themselves things like "what would the customer want" or "how can I design this to be as efficient as possible but still be understandable"? People who view development as simply a "day job" and don't take pride in their work end up causing themselves and others pain down the road. Being a developer should be more than simply writing code that works. You should care enough to write code that works and is elegant.
Care about the end user
Whether your code is a script that nobody will ever see, or a GUI application that people will use daily, a good developer puts themselves in the customer's perspective. They care about efficiency. They care about how the people who will use their software on a daily basis will perceive it, and how it will impact their workflow. Try to imagine how shaving even a few seconds off a process that someone does many times a day could add up over the years. With the power of modern computing, it's all too easy to become lazy as a developer and not put much thought into scalability, or to write sloppy code that doesn't make good use of resources.
Care about robustness and security
Writing good code also involves covering yourself in terms of error trapping. Make sure your code can (attempt to at least) fail gracefully when the unexpected occurs. Also, make sure you always code with a view to security. Way too much software is written in such a way where security and error trapping is put off until later. All too many times, due to time constraints or simply forgetting, these tasks never get done, and as a result insecure, buggy software is released.
Don't be afraid to start over
Good developers also aren't afraid to refactor their code. Sometimes it takes finishing a good chunk of code and analyzing how it performs in the real world to realize you did it all wrong and you need to rip it up and redo it. That's OK. Try to learn from it and do it less as you mature as a developer.
Memorize the headers and APIs you use most
Try to memorize headers and such of key APIs and libraries you use often. Personally, I find it all to easy just to keep looking up that function over and over whenever I need to use it. But if you trust yourself and memorize the documentation, then you can code more efficiently with less interruptions from having to go and look up that function call every time.
Keep it simple
It's easy for a developer to code "the kitchen sink" and bombard the user with a million options and settings. Yes, the program can do everything someone could possibly want, but overwhelming and confusing the end user is never a good idea. It's much better to think things through carefully and build only what is necessary, or if all the options must exist, build it in layers so the most important options are visible first, then the advanced users can dig in and configure to their heart's content.
Interest. Level of interest is the #1 requirement to find good developers. This is a field where you are constantly learning and if you are really interested in the technology you will keep learning better and faster ways to improve what you do and solve problems that you encounter without insisting a manager send you to training courses constantly.
It's a simple thing to measure in an interview too. Just start asking them to tell you about things they've built in detail. If you can't get them to geek out and show some pride in something challenging they solved or how they went about building it then it's a huge red flag.
So far I've hired 6 programmers via the geek out test and its worked every time to identify great developers. Sometimes they don't even need to know the language we use because their background and interest shows that they are more than willing and able to do so.
The GPP only claimed to be a "great" developer, not the best in the world. I personally think there's a pretty wide variation in skill in the industry, and it's not inconceivable that this guy worked at companies where his coworkers really were terrible. Maybe he worked at Microsoft in the 90's :)
A big fish in a small pond is still a small fish in the ocean.
He's a great programmer if others recognize he's a great programmer. Until then, he believes himself to be a great programmer; but, so does everyone else.
And yes, the old-timers will recognize this immediately as the definition of when a person can claim the title of "hacker" for those who still remember it's roots instead of the current "evil computer user" definitions.
A bunch of fanbois in Slashdot, Reddit, and the tech press saying so-and-so is a great developer.
Yep, I've never met a really good programmer who didn't use every tool he could exploit to find his bugs.
Good point. In that vein, the best programmer I ever worked with once said he had an "anti-fetish" for bugs. I think that at least partly explained the extremely high quality of his work.
For most of us, though, finding and fixing bugs is a chore that we'd rather avoid because writing code (and therefore more bugs) is more fun. I try to emulate the anti-fetish mentality of my friend, but that remains something that I sometimes have to discipline myself to do rather than something that comes naturally.
I don't know about great programmers.. but I've found some great qualities in coworkers who seemed great to me throughout the years:
1. Nice people: People who get along well with others and through their good qualities make everyone better. Not only can they write awesome code, but since everybody likes them they can get the knowledge they need to do it right. This is probably the quality I admired most in the GREAT programmers I've met.
2. Deceptively simple designs: I've met coworkers that can design things so simply yet so solidly that their designs last forever
3. Clean code: the write code that everyone understands.
4. Innovative: they are always finding ways to make the project better
5. Broad range: they always have a new trick in their bag. They always know about this tool or that that makes things better, or this library or framework.
6. Attention to detail: they are patient enough to write unit tests and go through the quality steps needed to guarantee good functioning of the code.
I think calling it a huge red flag is premature. I've had many projects that I've been very passionate about during the development process, but usually, when they get to a point where they are pretty much done, the excitement just drops and I can only see them the way an end user would see them. Just useful applications. The process was good times, but it's all in the past. I could tell you how everything came together, but hell if I'd be enthusiastic about it now.
1. Skill
2. Passion.
File under 'M' for 'Manic ranting'
If you don't know how it's going to look, behave, or function; then put the keyboard down and go figure it out before you do any programming. It's amazing how competent you will find yourself, when you know what you are doing.
I will not mourn that which I never had to lose. - Unknown
A lot of confusion arises by trying to find *the* one attribute that is more virtuous than something else, not recognizing that there are usually two opposite perspectives, each being appropriate in a specific context. You may argue that "top-down" is better than "bottom-up", but for a given context, "bottom-up" is going to be the better perspective. You may argue that it's better to optimize development time rather than product quality, but that's also about the context and about listening to the requirements of the customer. Maybe it's about collaboration and working in a team, but for a given context, doing something by yourself is still the way to go. Even when we're talking about how much we earn, it's about recognizing that it may be that we're giving in to corporate oppression rather than pursuing our dreams. Which is the right way to go -- not that easy is it? In the Western philosophies, we want to identify virtues and we want to label these virtues so that we know exactly what are the attributes of the "great developer". In Eastern philosophies, such as Taoism, you will recognize that a mountain has always two sides -- one in the light and one in the darkness -- and both are part of a greater whole.
So when business-type assholes say be passionate, they mean enjoy?
Or did you not "listen" (read) what he wrote? I thought being a good listener (reader) was key.
A job is a job, it's fine to enjoy it, it is not necessary to be passionate. I'm passionate about a lot of things, no one is going to pay me to do them. Work is necessary, for most of us, because we need money to live, and do the things we are passionate about.
That is the problem with the entire work world. People misusing language to create an environment that they think will cause people to give them 110% (hint, it's not possible. As an idiom, it's stupid. why not 1000% why not a baxillion %?. It's like that commercial from about five years ago about package delivery:
"If we don't get this package there by tomorrow, we're doomed!"
Sorry, most jobs are not worth being passionate about. They just aren't. It's a waste of your precious life to be passionate about what you just need to do to live. And stressful as well.
Comment removed based on user account deletion
As a security guy that has to find workarounds, patch holes, and generally makes a career through programmers making little mistakes, I see 2-3% error rate as being a normal coder. It is intensely rare to see anything remotely like secure code from any single developer. It takes round after round of iteration with a team of specially trained people to make anything worthy of being called secure.
The honest truth is that having a career as a programmer means more than making a good product. In fact that is probably the least important part of a programmer's job. Keep the boss happy, be reliable, and crank out things that work by deadlines even if they are buggy pieces of crap are likely to be the top three things needed to have a successful career.
In most places people don't like to think. Thinking is hard and people don't want to do it. Solving problems involves thinking and if you save people from doing something they don't want to do they will value you.
Even better is if you do the problem solving and leave them with the 'how-to', you will be idolized every time that solution is used and considered essential.
Agism tries to trump experience but it never works because agism is so naive, so if you can't avoid getting older then grow up slowly and enjoy IT for the fascinating career that it is. Keep the love!!!
If you are in it for the money - get out now, you have already failed.
My ism, it's full of beliefs.
I'm a crappy developer....
My key points on the subject are:
1. A love of the art and the job.
2. An eagerness to learn and try new things.
3. The willingness to risk your job to do "the right thing" on a project.
4. Acceptance that others in the business (not just the team) have valuable inputs that need to be respected.
5. Experience. Years and years of in-the-trenches experience with a variety of technologies and techniques.
6. (And perhaps most importantly) A background in the history of computing. The realization that "with a computer" or "on the web" does not make something "new" and patent-worthy.
I do not fail; I succeed at finding out what does not work.
The most important quality of a great developer is that it writes code. Go figure.
The second most important is that his code is appreciated by others.
The third, but not less important, is that said others actually want to pay for said code. Yes, that's a quality, because it implies making things people want and are useful.
Out to write some useful code.
Software development like almost everything else is about balance.
Do I refactor/rewrite or not? Add the extra layer of abstraction? write defensively?
Do I commit a partial solution to keep integrated with mainline?
Should I deploy a partial solution to get real feedback?
Do I make it more complicated to handle some future requirement?
The best software developers have a good sense of balance. You can always learn a new language/technology
you can also learn to do things by-the-book learning balance is tricky.
Joel Spolsky says a developer needs two attributes: "Smart" and "Gets things done"
I am beginning to believe the latter is the more important part.
I always recommend new graduates to take their first position in a big corporate environment and their second (and all future) in fast moving start-ups.
After you have learned the "anal" way of doing things you make much better decisions when cutting corners.
and that everyone around you is only outputting a bunch of shitty buggy crap, it's probably time for you to do a bunch of introspection.
Been there...except it was "the platform is horrendous" "the managers can't make up their mind" "noone accepted any of this -- pushed on the customer and pushed on our "agile" "scrum" (in name only) team....all deals were made ahead of time by higher-ups shaking hands...we just make-believe we are "Agile" and responding to customer requirements, when in fact everything is pre-determined and neither us nor the customers have any actual say (which is fine...but not "agile" and not "scrum" at all).
And yes, the legacy code was shitty buggy crap...that is why despite our shitty buggy crap (the whole platform was inherently immature) it was still better to start from scratch.
no, all of us: managers, customer, coworkers (of all skill levels) were all in agreement: this company is shit, this platform is shit.
but, of course, who is going to up and leave?
"everyone who had anywhere else to go already left" -- manager
sometimes it IS all shit. and the only people who stick around is for their mortgage or to pay for school (or for their kids' school).
and my boss hated our client...despised everything about them...they didn't return phone calls......but they paid the bills...even when we were "not dependent on them in any fashion" ...... there were periods we would literally sit 2-3 months doing nothing because the contact people on their side were busy with other things...but it was cheaper to pay us to literally do nothing than re-negotiate contracts.......
basically, when a "company" has gov. (taxpayer) funding them...they don't give a shit about anything except getting their lobbyists to buy off politicians.
and our "republican" "free market" company doesn't give a shit it is all a mirage...just as long as we are getting paid, who the fuck cares?
which is fine...but give me a fucking check if I am going to sit and do nothing all day, because I have shit to do.
and then magically, one day, there'd be "6 weeks of work we need done in one week" ... dysfunctional all around...
our "real" manager was MIA ..... off on another team.....it was a guessing game "who is our contact this week?" and "what project this week?" ........ it somewhat leveled off in the end, but you'd be amazed how long this went on :)
I can understand "restructuring" I suppose......I can't imagine getting paid to do nothing for weeks at a time....they liked us better than their in-house people is all I can figure...better to not piss us off or we'd drop them......they did not trust their own people :)
I have seen a familiar pattern (spectator and been the person involved): places who lay off sysadmins without bothering to verify:
1) anyone else actually knows how anything works
2) anyone actually documented anything
3) anyone knows what servers are running what
4) anyone knows resource usage, whether we need more (virtual) machines
doesn't give a shit about anything. they waste time and money (IMO) cuz a few weeks (perhaps a month) later shit stops working, and noone knows anything, and they find they need sysadmins and DBAs again....
in my case, nothing was documented when I came in; when I parted, I asked "don't you want our network diagrams / all the details of our internal network and machines and software, etc.? " and when the answer is "no" you basically know you made
the right choice.
some places....just do not give a shit about anything. the stock price rises, the shareholders make a buck....everyone and everything else is disposable.
existing customers are not where money is either...the money is signing up new accounts...it is just a mad rush and grab and while this might be financially necessary (not when you have endless gov. money pouring in, bu
My parents.
You need to be driven by and enjoy solving problems. Without that passion, you will probably not make it.
Also, the sad reality where I am employeed is that there is more to get done than I can do. So, being able to settle for "a" solution that buys you time can be a necessity. I'm a perfectionist. So, that's a bitter pill for me to swallow.
Great programmers don't waste energy. They are focused on meaningful results. This helps them avoid endless traps: over-identification with their own solution to a problem, practicing process for the sake of process rather than the results it enables, struggling for credit, cranking out code to meet suspect purposes and features, participating in office gossip or off-point meanderings that waste time. Great programmers focus on useful, deliverable results more intently than regular programmers.
To be a great programmer (or even just a good one), you need to never stop learning. Always be learning something. Many times in my life I have learned something on my own, only to be able to apply is a totally different situation later in life.
Great programmer are insanely curious. They want to know the how things work, why one solution is better than another, always improving. That is the key, always be improving your craft, and your knowledge.
I agree. However, too many people can't be bothered to be curious. At best, they just want to get the job done. If you're innately curious, you're going to spend time looking deeply into stuff that "practical" people don't consider worth looking at at all. You're going to try things and see what happens, whether you're a kitten or a developer or Albert-frickin'-Einstein. And that, after all, is what learning really is. You don't so much force yourself to learn to become great, you become great because you can't resist the impulse to learn.
You WILL make mistakes and introduce bugs when coding. A great developer knows this.
Ask anyone you think is a great developer, "What do you do to help prevent or detect the mistakes you make?"
Computers are devices whose primary purpose is to make developers look like idiots when they make statements about what the computer is going to do or not do.
Don't even get me started on photocopies and traffic lights.
It's a conspiracy, I tellya!
For most of us, though, finding and fixing bugs is a chore that we'd rather avoid because writing code (and therefore more bugs) is more fun
maybe that's the fundamental thing - the greater a programmer, the more he treats the work as work and not fun. A professional working on building a product and not some amateur playing with his hobby.
A great programmer will use whatever tools are needed or suitable, the 'coder' will use the tools he really prefers using. Like my mate, when presented with his new job that involves creating an updated embedded PoS terminal, rather than reusing as much of the legacy C++ code blocks the old system has and putting it on a Linux platform, is only interested in rewriting it all in .NET on Windows 7 (or 10 probably).
Yep, I've never met a really good programmer who didn't use every tool he could exploit to find his bugs.
Good point. In that vein, the best programmer I ever worked with once said he had an "anti-fetish" for bugs. I think that at least partly explained the extremely high quality of his work.
For most of us, though, finding and fixing bugs is a chore that we'd rather avoid because writing code (and therefore more bugs) is more fun. I try to emulate the anti-fetish mentality of my friend, but that remains something that I sometimes have to discipline myself to do rather than something that comes naturally.
Long ago, I had a set of "Programming Proverbs" books. I think that's where I ran into the term "anti-bugging".
Anti-bugging is simply the process of designing and coding so as to make bugs either impossible, or at least easier to detect. It can be as simple as always coding brackets around conditional clauses instead of only when needed, to pre-initializing variables so that in case all the various logic paths fail to set them that their value will be consistent (and ideally, obviously wrong). Coding tests to detect and report things that "will never happen". Because they do, alas. And so forth.
Recently switched to a company where most of the software group gets so wrapped up in the textbook OO to the nth degree, the latest tools, dicking around with trying to anticipate every which way code could get misused by some rogue coworker in the process making the code 15 layers deep, complex, hard to understand, etc.. That they have like zero velocity. Be pragmatic!
Laziness makes for great software developers. Great developers will slave for hours, days, lifetimes even, just trying find easier ways to do things.
"The wisdom of the Patriarchs was that they *knew* they were fools." --Master Foo
That depends on the "why" though. Currently, one of the thing that will prevent a company from growing is how hard it is to get resources. An argument could be made that good C++ devs are rare and expensive. PoS systems are frequently written in higher level languages, so you'll more easily be able to find people to work on it if you use one of those languages. So the time and money you lose rewriting it will be made back, often several times over.
C# is actually a pretty wonderful language, with its platform being its only real drawback, and depending on your scale, it may not even be a drawback. If your total cost of ownership of one of these PoS boxes was $5000, the 20 bucks (after volume licensing) for the OS wouldn't a big deal. .NET will also easily be able to consume legacy C++ code because it has decent interop for it (better than most other languages with C++ interop).
Now, the PoS I used to work on had a much lower TCO than that, so until .NET core becomes mainstream on Linux, it may not be the correct choice, unless the C++ interop become a factor. But keeping a PoS system in C++ is almost certainly the wrong choice. You won't get many super star devs willing to work on that kind of thing, so you need to architect accordingly.
I guess I've never known a great - or even good - programmer who didn't find it fun. (Imagine, for example, a concert pianist who didn't find playing the piano to be fun. Unlikely, at best.)
Of course, not ever aspect of a programmer's job is fun, so that's where professionalism comes in. Like many programmers, I don't always enjoy the documentation aspects of it, but that's part of what my employer is paying me for.
(BTW, the title of this thread makes me think fishermen are likely to be better at cod than great developers.)
An undying devotion to their craft and diligence towards completing their projects so strong it blinds them to how poorly they are treated (I would say paid, but that's subset of "treated").
That is all.
IMNSHO, the greatest software developer is one who writes his/her code in such a way that (almost) anyone can understand it; who writes unit tests in parallel with the code to verify that it does what it's supposed to do; who prioritises what it is supposed to do over what it might do.
If I deliver a piece of code which does what it's supposed to do, together with unit tests that show that it does indeed do that, and which anyone can read, then that's worth a whole lot more than:
- code that is so opaque that no one can tell what it does, let alone how to modify it
- code that will do heaps more things, at the cost of making what it was intended to do more difficult
- code that next has to be tested to verify that it does what it's supposed to do
And most importantly, code that takes so long to develop that the project gets cancelled. Nothing is more useless than perfect code that will be finished "any time now". Good enough code on time - much more valuable.
Carbon and time.
IQ
The salary advice is really awful in this article. Your choice is basically between having a job or having your job outsourced. If you're making $150k you can expect your job to be outsourced to a company that does it for half that. You'll be making $50k next because all the companies that do what you were doing have outsourced, and the only employer for someone with your skills will be the outsourcers. They already lowballed the companies to get the contract. So they will hire the people the companies fire in a year or two as their business picks up.
Do you speak it?
I'm usually one to avoid sounding arrogant but at this point in my career, having worked for over 20 years at a variety of companies (startups, Fortune 500, etc) and working with people of varying backgrounds (Microsoft, Facebook, Google, Amazon, Stanford, MIT, etc) I can say with 100% certainty that most software engineers have no idea what the fuck they are doing. I'm far more humble in real life but just being brutally honest here.
The best software designers and developers are good software users. They know what to expect, and they make their software do what users expect. Don't forget that your fellow developers are also "users" of your software - they get to maintain your software after you are gone. Be the type of developer whose code is a pleasure to maintain.
The worst software designers I've encountered don't think like a user - many of them think like artists. They can draw a beautiful screen layout, but they don't think about how the software will actually work. The worst developers just assume everyone will use the software the way they do, so they don't do the extra work to make the software work smoothly.
I have yet to meet a really competent programmer. I don't consider myself much beyond capable - but I have too many flaws in my output to be considered really brilliant.
I have worked with or dealt with the output of other programmers who's performance was egregious - most egregious was the contractor who's naive use of a commercial java framework managed to produce the effect of a memory leak in java (e.g. hamstrung java's built-in garbage collection mechanism).
Experience has taught me practical measures of quality programmers in no particular order:
1. They must know how to program at the most simple level (e.g. competency in structured programming in C would be a good starting point - a basic understanding of LISP programming a plus) before tackling more complex programming tasks. I get the sense there are a lot of cut-and-paste programmers out there who really don't understand what the underlying code they are creating is actually doing.
2. Have an innate ability to focus on simple solutions, rather than being clever. KISS principle must be understood and brought into every design decision from the start. That is not to say there are no complexities, but understanding what is simple given the problem at hand - some simple things are complex when compared to other systems - and having the ability to avoid needless complexity.
3. Literate - must be able to not only communicate effectively externally - but also their comments in code should illuminate the subject matter in a clear, concise manner. Ideally should be able to get workable technical documentation straight from their comments - via doxygen or the like (perldoc, pydoc etc).
4. Their code must be maintainable and extendable. If an average programmer cannot maintain the code, and is required to rewrite the system from scratch - then you have failed as a quality programmer. Change is inevitable - how resilient your system is to change is a measure of your ability as a programmer.
5. They must understand a lot about technology outside of the world of their application. Their application will live in a world of networks, machines (physical and virtual), storage systems, communication protocols, and APIs - they must understand the implications of software design choices given a set of environmental requirements. The best programmers not only know how to code up systems, but also how to give advice about what their systems will be capable of doing given the environment, or lack thereof - and act upon that if it is possible to adjust via changes to software alone (e.g. choosing multithreading/multiprogramming design over single thread of execution).
6. They must be able to create secure code. If the company they work for doesn't produce a guide to that, then they should develop that on their own - and live by it - and consistently improve it. If they are using frameworks/libraries written by someone else, they should audit or test it to be sure the underlying implementation is secure.
7. Must be able to get along with others and work as part of a team; ideally if they are really a quality programmer, I would expect them to also mentor and share their ideals and capabilities with their peers to bring everyone up as much as possible. Quality programmers are not primadonnas.
That's it from my standpoint.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
....are developers who embrace the entire product design cycle, that includes business analysis, testing, and support. That means mainly not having the attitude that requirements are never to be questioned and once something compiles with less than three dozen warnings the code is ready for production. Great developers are also not to snobby to reject taking on a customer support case, pitching in during regression testing before a release, or fixing bugs (that they put into the app). In short, great developers do not come across as a diva that leaves no opportunity out to state how awesome they are.