Not cut out to be a programmer?

[corinthos]

Has anyone without a strong math background or CS degree ever been drawn to programming. found it elegant and aesthetically pleasing, liked the creative aspects of it, the iterative process of fixing and improving (and the instant gratification you get as you see the improvements in new builds), found programming concepts stimulating and fascinating, and felt it may be a good career avenue to pursue for these reasons? ... only to find that you're not as interested in writing code to fix problems for customers at work or writing applications for work.. that you're more interested in focusing on specific things that interest and appeal to you.. which mostly means some project for yourself.. maybe eventually being good enough to write something for an app store and get some monetary gains from it.. possibly make a career out of it.. but you find that while you can swiftly debug certain issues and others you can't seem think clearly and efficiently enough about to solve, and you find diversions or step away more frequently in order to try to reset and come back with fresh eyes.

It makes you wonder if you're really cut out for programming after all.. maybe it's best to keep as a hobby and not as a profession?

 

[urvile]

I am more interested in outcomes and doing interesting work OTH it can be incredibly boring work.....I find software engineering interesting also. Applying patterns, toolsets and processes to the design of large scale systems....

There is a difference between programming and software engineering. Particularly when it is done for a multi national that doesn't distinguish between building a satellite and building software. When it comes to methodology which means it is very process heavy and serious business.

For me it depends on the type of development also front end makes me want to shoot myself.

 

[sourceninja]

...

 

[DaveSimmons]

Software development is a mix of fun, non-fun, and anti-fun. If you'e getting paid to do it, you can't give up just because some parts are boring, or you're working with a library or tool that has bugs that you need to somehow work around.

I spent several days the week before last working around a design flaw in Google's Chromium engine where it will use 1+ GB of RAM to decode a high-resolution JPEG that will be scaled down to (say) 300x300 on the page. The fix involved a certain amount of head-against-wall bashing since the steps needed were not really documented anywhere. It would have been easier to give up, but this massive RAM spike crashes our application and is causing support tickets. It was cool when the fix finally worked though. So a mix of fun and un-fun.

Like sourceninja said the mix is true for pretty much any job. Google a week in the life for most careers and you'll see the boring and bad parts.

 

[William Gaatjes]

I am not a math wizard nor have i a Computer Science degree.
I do a lot of debugging of electronic designs and also design electronic circuits for work and hobby as well. There is nothing more fun than to see something i have created come alive through software.
What bugs me most, is that i think of smart hardware or design in a certain way that even hardware flaws can be easily solved by software and always the programmers have another way of doing things that ends up in a lot of extra work for them for being stubborn or suddenly it is all too much work.
To see my creations come alive and think of things i want to build that need good software, is what has aspired me to take on programming as a hobby.
In my own time, i am not restrained by anything except my own imagination and my search, read and understand fu.
With software it is also letting go of ego when the wheel is already invented. If the software works and complies to everything on your wishlist, why would you start from scratch ?
Starting from scratch is only handy for educational purposes when you want to learn something.

It is 100% what the other in this thread say, sometimes you hate it for a moment, let it rest and do something else and they you are fresh and the answer will come to you when you have no prejudice.
An open mind is everything in solving problems.
That and deductive reasoning.

To be honest, i suck at all other kinds of puzzles because i do not care for it.

 

[urvile]

The fix involved a certain amount of head-against-wall bashing since the steps needed were not really documented anywhere

This. Sometimes you just have to keep going regardless.

 

[MagnusTheBrewer]

Fortunately, both professors and fellow students taught me programming wasn't for me not, because I couldn't do the work or didn't like it but, because I hated the personalities that worked in the field.

 

[corinthos]

I guess part of it has to do with the fact that when it's your job to code, you don't have the luxury of just stepping away for considerable chunks of time and revisit when you feel like it. You kind of need to keep pounding away in order to meet deadlines, aside from maybe stepping away for a day or so, or going to some other part of the project or another project entirely, just for a change.

But I agree that it's like most, if not all, other jobs... there's the good, the bad and the ugly.

 

[AMDisTheBEST]

I love programming but hate CS.

what is the difference between programming and software engineering exactly? I still had that part confused. When I saw BLS report programmer jobs are going to decrease but software engineering jobs are projected to increase, I was wondering what really is the difference between the two? What is a software engineer vs a software developer vs a programmer???

 

[nakedfrog]

IMO there's no fundamental difference other than title.

 

[AMDisTheBEST]

IMO there's no fundamental difference other than title.

Then why seperate category on BLS?
https://www.bls.gov/ooh/computer-and-information-technology/computer-programmers.htm
https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm

Is the naming just an excuse for programmers to demand higher wages or for BLS to hide true unemployment statistics?

 

[Chaotic42]

My understanding is that a Software Engineer is someone who works at a higher level of abstraction in the development phase, putting together different parts and modules which are written by programmers, who are generally given a fairly singular task and told to write a function or module based upon it. In the real world the titles seem to have very little actual meaning other than billing rates, at least in my experience.

I'm not any of these things, so this is just my experience - I'm not an authority.

 

[nakedfrog]

Then why seperate category on BLS?
https://www.bls.gov/ooh/computer-and-information-technology/computer-programmers.htm
https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm

Is the naming just an excuse for programmers to demand higher wages or for BLS to hide true unemployment statistics?

Couldn't tell you.

My understanding is that a Software Engineer is someone who works at a higher level of abstraction in the development phase, putting together different parts and modules which are written by programmers, who are generally given a fairly singular task and told to write a function or module based upon it. In the real world the titles seem to have very little actual meaning other than billing rates, at least in my experience.

I'm not any of these things, so this is just my experience - I'm not an authority.

In my current job, with no real change in duties/responsibilities, I've had all three titles (gone through a couple acquisitions). Currently a software engineer.

 

[Gryz]

I prefer the title "code monkey".
Too bad we don't do business cards anymore, or I'd have "code monkey" on it.

I don't think there is a difference between software engineer and programmer. Programmer is more like describing what you do, while software engineer is actually a job title. No software engineer will ever answer to the question "what do you do for a living" with the phrase "I engineer software".

There is a difference between programmers. I think a truly good programmer is worth more than 10 average programmers. And the benefit of having a bad programmer is actually negative. In the end it'll cost more to clean up the mess of the bad programmers than the value they have added. Too bad that most (large) employers don't see that. A good programmer can never make more than a bad manager. And a bad programmer will make at least half of what a good programmer makes. (Of course there are exceptions).

I think the success of software in popular products, or new successful products depends on a few individual star programmers. The guys (or gals) who create something out of nothing. And if it wants to be successful, the code has to scalable, robust, readable, maintainable, extendable, etc. Most programmers can probably hack something together that "works". But good software doesn't need only to just work. Imho bugs are the least important issue in software, when deciding how good software is. Bugs can be fixed. Bad design can often not be fixed. Unreadable or unmaintainable code is pretty much worthless in the long run. If you want good software (for a product that lasts a decade or more), you need one or more very talented programmers to get thing started (and finished). This is where you need software engineers with an education in Computer Science. Someone who thought himself some javascript or assembler won't do.

 

[Cogman]

What type of programmer you need and where you need them is going to depend a lot on the age of a product.

Speaking for myself, I tend to take a long term look at software and work towards solutions that are easy to replace, hack away, and maintain. However, that takes time to build those solutions and time is money. I personally have a hard time balancing "right" with "MVP". I tend to fall on the "right" side hard, but I realize that when a Hack will suffice that can be detrimental to a product. Depending on the life of a piece of software, the developer working on it can be "good" or "bad".

Young companies are all about spinning out lots of features and code fast to try and win new business. Unmaintainable code is almost inevitable and not going with it can sacrifice your market position. RethinkDB, I think is the case study here. I think they did pretty much everything "right" that mongo did "wrong". Even postgres is an example here. Postgres had minor market shares because they targeted correctness first and, honestly, they wouldn't be nearly as popular now if it wasn't for the oracle acquisition of sun/mysql.

However, these hacks and quick solutions have their toll. They make newer features harder to add. They make newer approaches harder to take. They make bugs harder to track down and fix. And they make it harder just to understand how things work.

I think the ability to safely refactor code is an important one. But businesses really need to understand how expensive it is to replace bad code with maintainable code. Nobody wants software that crashes frequently or corrupts things unexpectedly.

 

[urvile]

I love programming but hate CS.

what is the difference between programming and software engineering exactly? I still had that part confused. When I saw BLS report programmer jobs are going to decrease but software engineering jobs are projected to increase, I was wondering what really is the difference between the two? What is a software engineer vs a software developer vs a programmer???

Job titles are funny things. I have been a software engineer which involved very process heavy development and we actually designed components using OOAD etc. It also becomes a liability issue where your employer doesn't want to get left holding the bag if the project goes tits up and they get sued by their client.

They need to be able to turn around and say hey we used software engineers with four year engineers Australia accredited degrees. There are a lot of if buts and maybes. This is the Australian context of course.
Currently I am a software developer. Previously I was an SQL\.NET developer. The main difference with those roles is they use scrum or ad hoc agile which take a very different approach to things like qa and design.

 

[AMDisTheBEST]

Job titles are funny things. I have been a software engineer which involved very process heavy development and we actually designed components using OOAD etc. It also becomes a liability issue where your employer doesn't want to get left holding the bag if the project goes tits up and they get sued by their client.

They need to be able to turn around and say hey we used software engineers with four year engineers Australia accredited degrees. There are a lot of if buts and maybes. This is the Australian context of course.
Currently I am a software developer. Previously I was an SQL\.NET developer. The main difference with those roles is they use scrum or ad hoc agile which take a very different approach to things like qa and design.

That’s it??? Really??? To advoid law suits? Unbelievable

 

[urvile]

That’s it??? Really??? To advoid law suits? Unbelievable

I will give you bit of background but as I said this is in the Australian context. In Australia there is only one state with laws that specify when you can call yourself an engineer. I.e you must have a 4 year engineering degree from a recognised institution.

Every where else it is the professional body called engineers Australia that that regulates the industry. They have only recently recognised software engineering as an actual engineering discipline. However atm I can call myself a software engineer even though I don't have an accredited engineering degree. I can't call myself an electrical engineer though.

We could get to a similar point where only those who have an accredited four year degree in software engineering can be recognised as software engineers. The way these degrees work in aus is a student enters uni as an engineering student, does a common first year then specialises in mechatronics, mechanical, software whatever...

So software becomes another engineering discipline.

As for liability. If you haven't worked in certain industries and/or for a multi national corporation whose primary business is building weapons of destruction it can be a bit hard to understand.

 

[urvile]

That’s it??? Really??? To advoid law suits? Unbelievable

So. If you say build the control system for a nation wide tolling network* and the government that you are building it for is projecting a billion in revenue to be generated in say 18 - 24 months after it is switched on. Then a major flaw in your software causes serious issues and maybe it's not something that can be easily fixed. Like a design issue and the system cannot generate and store infringements and the client says well that's costing us 10 million in revenue each time it goes down. Now I am just a grunt down in the weeds I don't have anything to do with the legal side of it but if the company has used unqualified people to do the work then they leave themselves open for a serious reaming.

The same as if they don't use appropriate engineering processes which can go to the level of having periodic QA where people come in and ask to see where in the code a particular (or set of requirements) requirement has been implemented. It's all about self preservation basically. I have been doing this stuff long enough to have become cynical about the whole process. Just because someone has a software engineering qualification doesn't actually mean they are going to be any good at it but it does tick a box. It's the same as a hospital employing someone to work as a doctor without checking their qualifications who then kills a few patients and then it turns out they have a teaching degree or something.

*Although it's not actually being used for tolling but it does operate on the same principals.

 

[purbeast0]

There is a difference between programmers. I think a truly good programmer is worth more than 10 average programmers. And the benefit of having a bad programmer is actually negative. In the end it'll cost more to clean up the mess of the bad programmers than the value they have added. Too bad that most (large) employers don't see that. A good programmer can never make more than a bad manager. And a bad programmer will make at least half of what a good programmer makes. (Of course there are exceptions).

I could not agree with this statement more. This is so damn true and it's a shame that most companies don't realize this. I feel like some are starting to come around to it though. I'm very firm with my salary range when I'm looking for jobs and when I hear companies who are only offering like $90k - $100k for a senior software engineer position and they can't budge at all, I kind of laugh at it. They aren't going to attract good talent at that rate. They will only get the dime-a-dozen guys.

 

[Chaotic42]

I really wish there was more emphasis on documentation and technical writing amongst developers and software engineers. I took several CS classes at university after I got my degree, and I don't remember there even being a course for it. I sometimes have to take over or help out with projects because I can code, and the documentation is always some horrible wiki with incomplete environment instructions and entries like "This is broken, we have a work around, but will fix by end of year - Steve, August 3, 2007"

I'd be curious what you folks consider discriminators between good and bad developers.

 

[urvile]

I really wish there was more emphasis on documentation and technical writing amongst developers and software engineers. I took several CS classes at university after I got my degree, and I don't remember there even being a course for it. I sometimes have to take over or help out with projects because I can code, and the documentation is always some horrible wiki with incomplete environment instructions and entries like "This is broken, we have a work around, but will fix by end of year - Steve, August 3, 2007"

I'd be curious what you folks consider discriminators between good and bad developers.

Documentation is another funny one. Typically it's a mythical beast. Like a unicorn. There are different types of documentation too. Usually it's written or vetted by technical writers which costs money. Sometimes the documentation is a deliverable so the cost gets passed on to the client. This includes peer reviews.

In my general experience documentation doesn't get written by developers due to time and cost constraints.

When it comes to good vs bad the key points have been hit already. Someone who can design and write coherent and maintainable software is good. People who write crap so bad that has no design and is basically free-form coding with so many bugs that are impossible to fix without causing more issues. Then you have to hire someone else to spend 2 years re writing it are bad.

 

[Alpha One Seven]

Has anyone without a strong math background or CS degree ever been drawn to programming. found it elegant and aesthetically pleasing, liked the creative aspects of it, the iterative process of fixing and improving (and the instant gratification you get as you see the improvements in new builds), found programming concepts stimulating and fascinating, and felt it may be a good career avenue to pursue for these reasons? ... only to find that you're not as interested in writing code to fix problems for customers at work or writing applications for work.. that you're more interested in focusing on specific things that interest and appeal to you.. which mostly means some project for yourself.. maybe eventually being good enough to write something for an app store and get some monetary gains from it.. possibly make a career out of it.. but you find that while you can swiftly debug certain issues and others you can't seem think clearly and efficiently enough about to solve, and you find diversions or step away more frequently in order to try to reset and come back with fresh eyes.

It makes you wonder if you're really cut out for programming after all.. maybe it's best to keep as a hobby and not as a profession?

Programming sucks.

 

[Gryz]

I'd be curious what you folks consider discriminators between good and bad developers.

This is a very interesting question. And it would deserve its own thread.

One statement that must be made first is that you don't always need the best programmers. Software that is developed for short-term use doesn't need to be perfect. (Say used for a few years only, not decades). The fewer people use software, the less important it is, and the less important it is that that software is perfect. If you build something that has been built many times before (e.g. a simple website, or an accounting tools with a GUI), you can use standard tools and standard practices. That stuff is simpler.

The challenge comes when you have to build something that is really new. Or something that has to be really fast. Or something that has to scale to thousands or millions of users (or in my case, billions of users). Where you need to think about the overall architecture, where picking the wrong tools can break a project, where every algorithm you use has to scale.

For me personally, the most important property of software is maintainability. And for me, that means a new person, with a decent amount of experience, has to be able to understand what the system is doing. The architecture has to be not overly complicated. There must be a little bit of documentation of the overall ideas and goals of the code. And all the code has to be commented, good function-names and variable-names. It must be clear that the people who wrote the code were aware that someone was gonna come in after the original coders, and those people would have to maintain the system. That is a hard job. I want the original programmers to acknowledge that their successors will have an evenharder job than they had. I want them to think ahead. And try to helpo their future successors.

I don't care about bugs. When you write code, there will be bugs in them. I don't care if there are few bugs or very few bugs. (Of course you shouldn't write code with a dozens of bugs in every function). Software needs to be tested anyway, and you can then find and fix most bugs.

I don't care about speed of execution. Not at all. I do care about scalability. If your software works with a 1000 thingies, it doesn't matter if it takes 100ms or 200ms to execute. However, if you grow your thingies from 1000 to 1 billion, it would be nice if execution time grows from 200ms to only 10 seconds (O(log n)). Not linearly (O(n)) to 1m * 100ms = 100k seconds. Or god forbid, it has O(n*n) complexity. (If you don't know what O(n) means, or what an algorithm's complexity is, go look it up. It's one of the most important concepts in computer science).

Again, the most important property of software is readability. That's what makes the distinction between average and good programmers, imho.

 

[urvile]

f you don't know what O(n) means, or what an algorithm's complexity is, go look it up. It's one of the most important concepts in computer science

This is an interesting point. I have had the experience where I was on a team were we had a mixture of qualifications but we had a guy who was doing the UI and once the dataset he was rendering got to a certain size the UI would choke. He was trying to render 100,000s of rows at the same time using a loop that was executing in quadratic time. He didn't have a CS background and he couldn't figure it out. Our tech lead who did have a (advanced) CS background had to diagnose and fix it for him. Which IIRC was reading the rows from a cache in manageable chunks.

Complexity doesn't come up very often for what I do (hey it's .NET) but if you don't know big O it can be problematic.