|
Most manager are chaotic neutral. Any inherently good or evil actions are simply a lack of self control and occur by accident.
|
|
|
|
|
I learned very early in my career that I was forever meeting and working with people who were far better developers than me. Which was a good thing because it gave me levels of ability to strive towards. But I never considered myself a good developer, just that occasionally I managed to produce some good code. Unfortunately I continued to make many mistakes.
|
|
|
|
|
If you were a mechanic, would you question your ability because you aren't skilled in all areas: general repair, electronics, small engines, diesel, foreign imports, jets, planes?
Probably not.. you'd have your areas that you were capable in and work from there; you'd probably work on expanding your skill set, but I don't think you'd expect you MUST be able to be an expert in all areas.
So... why do we, as developers, think that we need to keep current with an ever changing playing field?
My career started with Fortran, VAX/VMS and FMS Forms; it grew to include OSISoft PI systems and then C and Ingres. Next up was Windows development, SQL Server and Oracle.
Now.. I work primarily with OSISoft based technologies - I touch Windows development and SQL Server, but only in that they are required for the core technologies I use.
|
|
|
|
|
virang_21 wrote: In today’s market there is ever growing expectation from developer to be proficient in whatever technology is hot at that time and there are quite a few at any given point in time. Not only you need to know that technology inside out you are expected to know any other tools, libraries and frameworks build around it. It makes you question are you really a good developer even if you don’t know latest technologies or tools ?
This is mixing apples and oranges.
For the TLDR folks:
Good developer: overall skills and technical knowledge in specific areas capable of learning new things.
Good fit: a person with the specific skills the business needs now.
Those are two different things.
Longer read:
First off, I'm a good developer because I have a lot of (what I think is) very good overall knowledge, practices, work ethic and discipline, including skills such as communication, documentation, thinking outside of the box, and so forth. I'm also a good developer because I can learn new things -- business processes, technologies, etc. I'm also a good developer because when I start on a project, I ask a lot of questions, I assume I know nothing, I ask why decisions were made that are contrary to how I would have done things, so I can learn what the trade-offs were, and I constantly look at what I'm doing and work on self improvement.
On the other hand, if a client / employer needs someone with a specific expertise to immediately jump in and work on something in which I don't have those specific technical skills, then I am not a good fit for their requirements. That does not mean I'm not a good developer. It only means that for their business requirements, they can't afford the (sometimes considerable) tooling up / training that I would need.
Obviously, there is the third camp, let's call those people junior developers, that are neither good developers (and hopefully will be one day with proper mentorship) nor have the technical skills. Those are the people that companies are the most reluctant to hire nowadays. The idea of grooming someone just out of school, building a long term relationship with them, having incentives for their staying with the company, etc., those days are for the most part long gone, partly because of market forces and partly because companies more and more treat people like replaceable cogs in the wheel, when actually they are not, especially once they've learned a lot of the intangible knowledge of the specific business domain. I'm not saying anything original here, this issue has been written about for years.
[edit]
The other thing about modern development, and something that seems to be not fully recognized, or worse, ignored, is that the days of one man development are pretty much over. It really does require a team nowadays - front end, back end, middleware, source control, documentation, testing, QA, deployment -- and in that world, while it's still important to know your particular area of expertise well, communication, organization, and "higher level" skills are becoming (IMHO) even more important, and also what I find generally lacking are the people that can glue it all together well. You might call these people "architects", but they are certainly not the typical product/project manager.
[/edit]
Marc
modified 3-Dec-16 11:04am.
|
|
|
|
|
Eloquent, as expected, Marc: I like the focus on "fit;" I wonder if that might be extended to thinking of hiring (at its most "rational") as being a cost/benefit analysis which weighs immediate fitness, potential fitness, and long-term adaptability in an industry where hardware, and software tools, will change radically every few years.
I spoke today with a former colleague (in the U.S.) from my years at Adobe; he's 59 years old, has a stunning resume: he says he's unemployable right now in Silicon Valley, and he believes that his age is a factor.
Did you ever read Coupland's book, "Microserfs" ?
thanks, Bill
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
BillWoodruff wrote: Eloquent, as expected
High praise, coming from the man that defines eloquence!
BillWoodruff wrote: he's 59 years old, has a stunning resume: he says he's unemployable right now in Silicon Valley, and he believes that his age is a factor.
I wonder about that, being 54. I wonder about the CTO of my former employer saying "I'm going to hire a bunch of young junior developers." It's rather shocking that a person in SV with tons of experience can't find a job!
BillWoodruff wrote: Did you ever read Coupland's book, "Microserfs" ?
No, but it looks quite interesting. I'll put it on the reading list.
Marc
|
|
|
|
|
I agree, Marc's post hits a number of critical points.
BillWoodruff wrote: I spoke today with a former colleague (in the U.S.) from my years at Adobe; he's 59 years old, has a stunning resume: he says he's unemployable right now in Silicon Valley, and he believes that his age is a factor.
This raises a key point, that there are two sides to being a developer: For the employer/customer and For yourself.
These are quite different. Being a good developer for the employer/customer means being the person who (typically) works with a team to solve business problems, using all the skills and abilities that have been previously noted.
How do you be a good developer for yourself?
By staying marketable.
We have to remain in "education mode" for our entire careers. Technologies come and go, so we have to learn new things to remain employable. I've seen too many people ride a technology into its oblivion, then wonder how they are going to find another job since they don't have other skill sets.
Technology is like the Lernaean Hydra, chop one head, at least 2 more grow from the stump. It's not possible to learn it all, so we have to make informed decisions on what to pursue. That gets easier as we gain more experience, we learn how to better choose which technologies to pursue. [Corresponding with others online certainly helps in gaining perspective.]
Couple this with improving the non-technical skills like problem solving, business astuteness, listening to customers, etc. This keeps us marketable.
Is this really different from being a good developer for the employer/customer?
Yes -- the difference is a matter of focus -- one side is for others while the other is for ourselves. They converge in the same place (being a good developer), but without devoting time to our own needs (marketability), we may end up without a marketable skill set.
Regarding Bill's friend who can't find a job in Silicon Valley -- ageism is a separate issue. There are places that are happy to hire the experienced people. Maybe not the "hot" employers ... but I have had several jobs in recent years where no one under 50. The client wanted experienced people who did things right on the first try. Unfortunately, Bill's friend might be forced to pull up roots and move to find such a place. After years of living in a place, that can be rough. 
|
|
|
|
|
virang_21 wrote: In today’s market there is ever growing expectation from developer to be proficient in whatever technology is hot at that time and there are quite a few at any given point in time. Not only you need to know that technology inside out you are expected to know any other tools, libraries and frameworks build around it.
I'd rather not work for someone who has those kinds of unrealistic expectations. I'd rather work for someone who values one's ability to learn and adapt to any new technology being thrown at them.
That is, by far, the more valuable skill.
|
|
|
|
|
virang_21 wrote: In today’s market there is ever growing expectation from developer to be proficient in whatever technology is hot at that time and there are quite a few at any given point in time. Not only you need to know that technology inside out you are expected to know any other tools, libraries and frameworks build around it. It makes you question are you really a good developer even if you don’t know latest technologies or tools ? You don’t know those technologies because up until now you did not have a need to use it in whatever application you are building. Just because AngulrJS sounds cool and everyone is using it I must use it ? One thing I have felt is if you don’t use today’s latest fad you are perceived to be old school and at times will not get a chance to even be considered for a new role.
The problem, I think, is that people tend to equate libraries and frameworks with technology. They're not. They're approaches to problem solving at best, and like all approaches they involve trade-offs.
The bigger question is: can you write good, stable, and functional code without the new toys, understand what frameworks are doing, and play nice with them by doing a careful code-walk (assuming they're not a steaming pile of garbage, which many are).
So there's an easy answer: the only objective measure of if you're a good software developer is if the software that you develop is good. That's the only thing that matters; libraries and frameworks are just tools to achieve that end, and that's all that they are.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
I am paid well, so I am a good developer.
|
|
|
|
|
I'm paid adequately, so I'm a 'good enough' developer.
|
|
|
|
|
virang_21 wrote: I don’t know all the latest and greatest frameworks and tools out there.
That's where you failed.
|
|
|
|
|
I haven't met anyone with balls big enough to tell me I'm not, at least, not to my face. 
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
So, from the safety of the Internet...
...
...
... Nope. Still can't do it*.
* Mind, your portfolio of articles here kinda denies the possibility, anyway.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
What makes a good developer good? First, it's providing value. Oh, the buziness bullshit bingo, it basically means providing solutions for the problems. Second, you need to strike a balance between having tuned your brain down in the 60s and always chasing the new cool kid on the block (JS frameworks, anyone?) Both extremes are dangerous, you need to find a path in between. Third, right tool for the job. Python may, once again, be the cool kid on the block and not even the fashion of the day but pretty much here to stay, but why should I use it? At work, I use Delphi which does everything that Python does and as a matter of fact, it does it better (at least until Python 3 which cleans up a lot of bad decisions in the language design). That's indeed my main motto: The right tool for the job. I recently introduced a couple of C++ features into a C codebase for two reasons:
1. Low cost. The compiler is a C++ compiler already so no changes to the tool chain
2. Wins in maintenance. I will never get the upside of manual memorry management and while my coworkers indeed have tuned out in the 60s, I prefer using the last decades of CS to my advantage.
Low cost, quite the win->Do it immediately. Porting the whole thing to Delphi (or Python) would have been way more costly with more benefit yes, but with quite the high costs of throwing parts away that, while they do look like the jungle, are at least well-tested.
|
|
|
|
|
I like being a Developer,
which to me is "Develop"
not just coding, not just designing, not just maintaining, not just deploying, but bits of many disciplines.
as for learning new stuff, mainly frameworks. What I found with Javascript, is that I started with Bootstrap and some Knockout, but eventually have stripped some things back to JQuery for more pure Javascript.
These frameworks (following applies more to Bootstrap) are tools to remove some of the "mundain" code a lot of common projects require to get started. But if you know how to write a html table in JQuery, there is not much need to port it over to be done in AngularJS, performance might even be worse on larger projects.
or the dozens of minor tweaks that business asks for, that some frameworks just get in the way.
|
|
|
|
|
Only good developers struggle with this question.
Bad developers don't.
|
|
|
|
|
While I ask myself the question, I think your focusing on the wrong aspects of what a good developer is.
I think in terms of are my solutions flexible? Can we easily add in requirements? Does adding in something make the next change easier or harder? (While there are certainly helps with some frameworks, these questions are framework agnostic.)
Also of importance is: Am I a relevant developer? If I need to find another job, will my skills translate? I currently love where I am. But I always want to maintain a place were I can change employers when needed.
|
|
|
|
|
A good developer is one who can solve the problems put to them and do it in a manner that meets the client's expectations as elegantly and as safely as possible. My clients are my main yardstick here (I consider myself a "client" as well because I develop stuff for my use). If they're happy with the solutions I provide for them than I guess I'm "good". I also really enjoy the process of developing code
If you, as a developer, are not constrained by some particular requirement involving your tools then you can choose what to use. My clients don't care what language, framework (or brand of coffee I drink) during my development work, they want their problem solved.
I've been at this for 40 years. Sure, you learn new technologies as necessary to be able to develop to the platform you are writing to at the time. However just because a new framework or tool is made available does not mean you have to learn or use it just because it's the "popular" thing to do. Until and unless your tool set reaches some point where it can't produce due to a major platform change or something then you are under no constraint requiring that you upgrade your tools or your knowledge set.
A lot of developers succumb to what I call the "lemming" effect. Just because their peers (or the market) is telling them they need to be using the latest and greatest framework or IDE or reporting tool they dutifully "follow the crowd". A little independent thought should tell you to evaluate whether making said upgrade would really benefit you as a developer. If not, just continue to be creative with what you have in hand.
I develop primarily for the Windows desktop and some light web applications. The focus of my development is to keep things as butt-simple as possible. It's not easy to keep things simple when you're constantly in upgrade mode.
I'm rambling now ...
|
|
|
|
|
I started "consulting" very early on; saw the inside of many shops.
Usually it was management's "style" that dictated how "good" IT's development efforts were.
|
|
|
|
|
What is the bloody point of commenting when everyone is a fool?
|
|
|
|
|
I was thinking about this very thing when I was reminded that a younger member of my team said that anyone over 54 is incapable of learning new things. So whether or not I'm a good developer, seeing that I'm an old developer now, it's irrelevant - I'm destined to become soylent green.
Tate Antrim
All around nice guy!
|
|
|
|
|
Tate Antrim wrote: I was thinking about this very thing when I was reminded that a younger member of my team said that anyone over 54 is incapable of learning new things. So whether or not I'm a good developer, seeing that I'm an old developer now, it's irrelevant - I'm destined to become soylent green.
Glad you didn't listen to the young smart-ass. Glad I didn't either. I'm about to turn 59 myself, I haven't figured out how to stop learning yet. 
If you think hiring a professional is expensive wait until you hire an amateur! - Red Adair.
|
|
|
|
|
I've never considered myself a great developer. Even when I left a big company to start my own, where I was supposed to be the Dev-Guy. But I knew I was capable enough. More importantly, I was willing to do the following:
1. Listen to and really understand the needs of my clients.
2. Focus on how to make the UI work most efficiently for the end user.
3. Research to figure out an (not the!) appropriate technology for the solution.
4. Learn whatever is needed to use this technology - even if this is a completely new framework.
5. Work my backside off to get the solution implemented well.
6. Iterate as many times as required on #2 until it was right.
Personally, I think I am a rockstar at #2 and #5. But a great developer - no.
Leaning on the shoulders of giants, and following these steps, we almost always got the job done - for desktop, web, embedded, and hardware projects. And having been in business for over a decade, I guess we have done a few things right. Most importantly, now when I hire, I look for those who are always willing to work hard, learn, and improve.
modified 5-Dec-16 12:44pm.
|
|
|
|
|
I can count on one hand how many great developers I have worked with in my long career of 44 years (42 in the corporate environments).
I have lost count as to how many people I have worked with who thought they were great developers but in my view weren't. One such developer actually came over to my cubicle one day and stood there for around 20 minutes telling me how great he was as a trading developer.
Though I have been considered during my career to be a "super programmer", I just saw myself as someone who was very good at getting a job done with professional quality (or at least as much as my technical management would allow).
Many developers today seem to feel that they are good if they know all about DevOps and Agile, have worked in such environments, and have gained a knowledge of all the latest tools.
The problem is that all of this does not make a great developer or even a good one. I have worked with such people and have found them to be mostly meh... Yes, they could put an application together and quote the latest technical jargon. And they could one-up themselves quite well. However, could they get a professional quality job completed with coding that was very easy to read and understand. No.
One fellow I worked with who claimed to be highly knowledgeable couldn't understand one of my application's code-bases when it was left to him when I went on vacation.
My source-code was in fact very straight-forward and eschewed all the latest techniques in OOP programming. The application simply didn't call for it. Unfortunately, this poor guy couldn't understand the code without it being completely object-oriented including inheritance (which is a time-bomb simply waiting to go off if it is not implemented properly).
None of us are really great developers since quality code can come in many different varieties, all of which fulfills the requirements it was designed against. This is not a competition, though many make it appear to be.
What makes you "good" is if you can get a variety of tasks done with professional quality within a reasonable time period. DevOps, Agile, and the latest tools, practically all of which merely reinvent existing wheels that already work quite well, are nothing but distractions.
Besides, no one can keep up with all of this hype that is being promoted all over the industry.
I don't use ASP.NET MVC, JavaScript frameworks, fancy CSS, WPF MVVM, or database ORMs. All of it is just doing the same things that were already defined with earlier technologies that still work exceptionally well. Nonetheless, I can still produce a quality application that no one will ever have to complain about, which is exactly what a user wants since they really don't care about all your tools, design patterns, and whatnot. They just want your product to work and work well.
If you do that you are doing just fine...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
