Showing posts with label programming. Show all posts
Showing posts with label programming. Show all posts

Programming Myths and About Coding

Overhead view of a desk with a laptop and hands over the keyboardOver on LinkedIn, I wrote a post about 5 Steps to Starting Your Programming Career (and Three Ways to Become the Best) and received a variety of comments from interested individuals. With an entire list of languages (which I'll get into later) at your fingertips, there's no better time to get into programming.
But some beginners are skeptical about coding. Don't I need a special skill? What classes should I take to learn about programming? What courses are available?
There are a lot of myths flying around on the interwebs and I thought we'd address a few of them today.
While some individuals see coding as waving a magic wand, some people downplay the amount of work it takes to write a truly effective, maintenance-free system.
Cartoon about a alien as a programmer with people looking at him weird

"It's Not Rocket Science"

Before we start into the myths, I want to explain that while some people have the aptitude for programming, some do not. Early in my career, when I was young and naive, I was talking to a Senior Analyst about the details of an application we were writing. The details of the application seemed simple and should've taken only a week to finish.
I said, "This should be really simple. I mean, hey, it's not rocket science..."
He quickly replied back, "No, it's computer science."
The "simple" details took over three weeks to write and put in place. Whoa! As I've said before, nothing is ever easy.
The moral of this story is that when it comes to writing code, you can write something extremely fast, but in the end, it's a balance between science and art. Sometimes you need to see the forest through the trees.
So, let's get into the myths, shall we?

Do I Need to Have a Math Degree for a Programming Career?

This is the most common question I'm asked from developers who are just starting out, and it's the biggest myth around.
If you are looking into developing games, I understand that there are a number of coding engines out there (like the Unreal engine, which is free), but understanding mathematics like algebra and calculus is required when working with PoV (point-of-view) angles and collision detection along with the X-Y-Z axis.
It all depends on the type of programming that you want to focus on in your career.
Gaming, AutoCAD, and financial analyst (think Excel) are just a couple that come to mind.
For writing business applications, utilities, websites, or databases, a basic math degree is enough to move you forward in your programming career, but it doesn't have to be your major.
The characteristics of a developer include logical reasoning, problem-solving, creativity, and a lot of patience, along with a mastery of your primary language and a general knowledge of design patterns.

As a Woman, Should I Get Into Programming?

Absolutely! I've worked with a number of women in my career and each one of them has shown a higher level of development along with a strong understanding of programming architecture.
I know truly amazing women (I'm talking about you, Josie, Carey, Shivani, and Amanda, you F# wizard, you!) and I respect each one of them and consider them an equal (or better) when I have a programming issue.
For the women debating whether coding is right for them or not, try to find the language that best fits your career choice and start using it in your free time.
It takes time to truly understand a programming language and its idiosyncrasies. If you don't like it, drop it and move on to the next language.
I absolutely believe that this is the best time for women to learn how to program.
As a matter of fact, the National Center for Women in Technology reports 25% of professional computing occupations in the 2015 U.S. workforce were held by women...and it's growing!
The amount of programming jobs continues to grow every year as the demand increases for even more people to become code-savvy.
So, definitely dive into programming. It's not going anywhere anytime soon.
Image result for programming

Should I Use "If" Statements If They Add Complexity to an Application?

During the same time period as that rocket science comment, one of my friends and coworkers said his brother made the comment: "If you were to create a truly object-oriented application, it would have no if/thens in the code."
At the time, I called bullshit. Again, I was naive.
Now, as I look back to 1994, I realized he may be right.
There is a term called cyclomatic complexity that Wikipedia defines as a software metric that defines how complex a program is by the number of branches in the code (i.e., if/then and switch statements).
For example, consider a situation in which we use a customer object to determine if the control is enabled or not, like this:
if (customer == null)
{
    enabled= false;
}
else
{enabled=true;}
We've all seen this type of code. Each section of code in the true and false block will increment the cyclomatic complexity since there are two branches.
It would be better to write this code.
var enabled = customer != null;
The less if/then and switch statements you use, the more developers may understand the system better. Maybe this is why I have issues with switch statements. *Shrug.*

Learning a Language Takes a Lot of Time

Once a developer finds their comfortable language, they feel like they can write anything thrown at them. They can conquer the world. 
Until that time, you need to experiment and try out some new languages once in a while.
It also depends on your career.
  • Web development? C#, Java, PHP, HTML, CSS, JavaScript.
  • Fat executables? WPF (Windows Presentation Foundation), C#, Java, C++, C, Assembly.
  • Database administrator? SQL, Oracle, Firebird, mySQL.
...and on and on and on.
Since there are so many career paths and choices, some web technologies are the obvious choice for this connected world. However, there are a number of Microsoft technologies that you can strive for as well.
Once you have a career path, it's time to focus on the languages that interest you the most.
If you look at the TIOBE Index chart (also refer to the Programming Language Popularity Chart), you'll notice that the top five are Java, C, C++, C#, and Python, in that order, with JavaScript closing the gap at number six.
Since JavaScript is the lowest common denominator, it would seem the most logical to learn if you wanted to get into web development. Learn JavaScript first so that you can appreciate the underpinnings of every single MV* frameworks out there written in JavaScript.
The bottom line is that you don't need to learn every single language out there to become a programmer. What you should do is: 
  • Understand the concepts of one language.
  • Experiment with ones that intrigue you.
  • Stick with the ones that accomplish what you need.
  • Become comfortable with your go-to language when one doesn't provide enough to reach the finish line.
Once you grasp the concept of a for...loop, it is essentially the same concept across every other language you encounter in your career. As I've said numerous times, a language is a language is a language.
It will get easier to learn new languages once you understand one or two.

I'm Too Old, So I Can't Program Anymore

My grandfather always said that age was up in your head. I know, I know, so long as the body is willing, you can do whatever you put your mind to.
In my mind, there is no such thing as too old.
I guess my point to older developers out there is to always be learning and continue to be passionate about your craft. Programming is more that just throwing code at a digital canvas and seeing what sticks. It's more than that.
It's your personal experiences and wisdom you've learned over the years through the school of hard knocks, the design patterns and practices, database considerations, scalability, usability, JS frameworks, performance issues, web services, SOA, and web APIs.
All of that!
I understand that there is a lot of competition out there, but over those years of work, you have tenure in your career. Valuable years of experience.
You also have contacts. As you moved through your career, you made contacts (using LinkedIn, riiight?). These contacts, whether they be recruiters or co-workers, know how you work and understand your potential, what you've focused on in the past, and what you want in your future (you could tell them, they know you!).
I always have a list of top recruiters in my LinkedIn account who I keep in touch with and vice-versa. If they treat me well, their "stock price" on the Danylko stock exchange goes up. If they don't assist when needed, they slide down my list.
However, don't always rely on recruiters (although the good ones do help in a pinch).
Always keep your skills up to date and your contacts active on LinkedIn and you should always have something in your field.

Conclusion

I hope that this post has brought some light to some of these programming myths.
At 46, I've been programming for over 25 years professionally and I have no intention of slowing down or stopping anytime soon.
If you have confidence in what you do, passion for your craft, and enjoy accomplishments through code, it's not considered a myth. It's a gift.
I hope that my fellow coders out there feel the same way as I do.
Do you know of a programming myth that needs to be debunked? Post your comments below.
Share:

Introduction to programming languages

Image result for programming languages

Programming Languages:

A set of words, symbols and codes used to write programs is called programming language. There are different type of programming languages are there for different type of tasking to be done in different programs.

There are two types of computer programming languages.

  • Low level Programming Languages.
  • High level Programming Languages.

  1. Low Level Programming Languages.

These programming languages are near to computer hardware and far away from the human languages. So the computer can easily understand these type of programming languages. When we are going to write in a low level programming languages when we should have a deep knowledge of the internal structure of the computer hardware. Low level programming languages are machine language and assembly language.

  • Machine  Programming Language.

This Programming language have only two digits to write programs. 0 and 1 this is called binary system. Machine programming language is the only language that is directly accepted by computers and its fundamental language of computer systems. Machine programming language belongs to first generation language. Its very difficult for humans and easy for machines. 

  • Assembly Programming Language.

This programming language is also low level just one step forward to machine programming language.  This assembly programming language uses the symbols instead of binary code.
These symbols are called mnemonics. Assembly programming language is called symbolic language. However assembly programming language is easy for humans than machine programming language.
Image result for programming languages

       2. High Level Programming Languages.

High level programming languages are easy to understand for humans because these programming languages have human languages like words for example input output etc these are driven form English language. Programs are written in high level programming languages can easily to write and modify then low level programming languages. These programming can divided into these categories.

  1. Procedural Programming Languages
  2. Object Oriented Programming Languages.
  3. Non-Procedural Programming Languages.

  • Procedural Programming Languages

  1. FORTRAN
  2. BASIC
  3. COBOL
  4. PASCAL
  5. C

  • Procedural Programming Languages

  1. C++
  2. JAVA

  • Non-Procedural Programming Languages.

  1. SQL
  2. RPG
Share:

Learn programming


LEARN PROGRAMMING.


Here at Flatiron School, we believe that all of education should be ROI-based. To us, that means that students should go into a program knowing the exact cost (financial commitment, time commitment, opportunity cost) and outcome (knowledge, skill, employment, etc.).

So how do you evaluate a coding bootcamp? There are two primary things worth considering:

1. Where is the best place for you to learn?
2. What is your goal?

LEARNING TO CODE

Some schools have rigid in-person curricula. Some are online. Some are completely self-driven. What’s best for you?

There’s no objectively right answer to this question. Think about getting in shape. Some people just need a pair of sneakers and can run outside and do pushups. Some people like to take classes or play team sports. Others prefer personal trainers. Each approach has its pros and cons, but at the end of the day, success is largely dependent on your own motivation. Figure out which environment brings out the best in you.

How should you evaluate the different immersive, in-person programs? Study after study has shown that one of the most important determinants of learning outcomes is the quality of the teacher. This should be obvious. If you took four years of high school math, you had four math teachers that (hopefully) knew the material. That did not make them great teachers though. Great teachers have the ability to inspire students to connect with a topic. Just because someone knows how to do something does not mean the person knows how to teach that same thing. What does this mean?

Evaluate teachers, not brands.

You shouldn’t be asking about the best “bootcamps.” You should be asking about the best teachers. The programming bootcamp industry is, for lack of a better word, bullshit. None of these schools existed just a few years ago and if there weren’t such a massive skill gap, few of them would exist today. If you were choosing between MIT, NYU, and Georgia Tech, you might want to take into account the name on your diploma. In any one of those schools, you’d be taking lots of classes, from lots of teachers, but what you’re signing up for here is really one single, intensive experience. In the bootcamp industry, however, no employer cares whether you went to one school over the other. All that matters is that you can do the work. And the best way to learn to do that is to have a GREAT teacher.

We’re pretty maniacal about teacher-quality at Flatiron School. We’d never have someone lead a course without TA’ing first and most of our instructors actually have backgrounds in teaching and programming. Avi Flombaum was teaching for years and had hundreds of students before founding Flatiron School. Ashley Williams, one of our Ruby instructors, was a NYC Teaching Fellow and organizer of the NYC Code for America Brigade. Jonathan Grover, our front-end TA, had the most popular front-end Skillshare class with 3,000+ students and 100% positive reviewsJoe Burgess helped create the iOS class at Carnegie Mellon before launching our iOS course. Peter Bell has founded tech companies and led technical teams as a seasoned CTO—he's also created a range of technical books and online courses and taught Digital Literacy at Columbia University. He now heads our team of online instructors.

We definitely don’t know every teacher out there in the growing bootcamp industry (though we’ve met our fair share), but there are some great ones.
Jeff Casimir, who founded Turing School of Software & Design, cares deeply about his students. He's passionate about education and is one of the most engaging speakers we've come across. I met Dave Hoover of Dev Bootcamp Chicago when he was at Starter League. His passion for education is infectious. Aaron Hillegass of Big Nerd Ranch has fantastic reputation. I haven’t met him, but we’ve used his books and spoken to many people who’ve taken his course. They didn’t just learn a skill—they came away inspired.

So when you’re evaluating a program, it’s a smart idea to ask some tough questions:
  • Who will be in charge of my learning? What is his/her teaching experience? Are the instructors on the site actually going to be teaching me? This is especially important for schools with multiple locations. Your high school/college probably had some great teachers and some awful ones. If you’re going all-in somewhere, make sure you’re getting the best resources.
  • Whom has that person taught before? Can I speak with some of his/her alumni? Do your research. Sure, alumni referrals are great. Find alumni on your own and reach out.
  • How much attention will I get? What’s the student:teacher ratio? Will I be getting personal attention from the instructor or will I be mostly on my own? If it’s an online program, what sort of instructor access can you expect? Real-time instructional support like in Flatiron’s Online Web Developer Program or 1x/week meetings?
ACHIEVING YOUR GOALS

You may want to get a job as a developer. Or start a company. Or get involved in the startup world. Or gain a new skill for your own personal development. Or something else entirely. The best thing you can do is understand your own goals and evaluate which program will do the best job of helping you achieve them.

On average, Flatiron School has a below-8% acceptance rate. With that sample size in mind, here’s what we see as some of the most common goals people have when applying.

Become a Developer: This is not the same thing as learning how to code. Some of the softer skills we think about includeL
  • Learning how to learn: Part of being a developer means being exceptional at learning new things. We spend a lot of time at Flatiron School “learning how to learn.” This manifests itself in soft skills (lock picking, yoga, knot tying, improv, etc.) as well as hard skills (students are required to learn new technologies well enough to teach them to other people).
  • Joining the community: The developer community is incredible, and it’s a huge reason why this is such a great field. Meeting the people that are pushing the limits of technology, and helping contribute to that, is an essential part of being a developer. It’s why every Flatiron student maintains an active technical blog and presents at a technical Meetups, and why we maintain such a focus on contributing to open-source projects.
Get a Job: In the same way that learning to play guitar does not mean you can play in a band, learning to code in and of itself does not mean you can be a productive member of an engineering team. Code is a team sport. It requires empathy, communication skills, collaboration. If you want a job, those skills should be prerequisites for any program to which you’re applying. Other than that, ask tough questions.
  • Dig deep on job placement. Lots of programs advertise really high job placement statistics. Are those recent? Are they self-reported or independently-verified? How did the last class do? Does that include people who dropped out or were kicked out? Are they counting people who accepted non-developer jobs? What about people with short freelance contracts? Or internships? Or people who couldn’t get jobs and decide to start companies? You can take a look at Flatiron’s independently-verified Jobs Report here.
  • Some schools claim to have “Apprentice” programs. Even online ones. What does that really mean?
  • Websites for these programs tend to be heavy on employer logos (especially online ones). Are those companies who’ve actually hired from the school or just ones that have shown up to a job fair at some point? What was attendance like at the last job fair?
Start a Company/Get Involved in Startups: Startups are awesome if you know what you’re getting yourself into. And seeing coding as your ticket to get a job at a startup or start your own is not completely unreasonable. But if your sole reason for learning how to code is to start or join a startup, Flatiron School might not be the right place for you. NYC has Startup Institute and General Assembly (company). Boston has Intelligent.ly. Those places are specifically designed to immerse people in the startup world. At Flatiron School, about 40% of our grads work at startups. But that’s not why they came here. People attend Flatiron School because their goal, first and foremost, is to be a great developer. If the next step on that journey happens to be at a startup, that’s great.

Become part of a community: Every environment has its own culture. Go visit. We host meetups more than once a week and typically have students presenting. Other places do “open houses.” Meet current students. Speak with faculty. Reach out to alumni. Visiting is the best way to get a real sense of what people are learning, and what the culture is like. Also if the school is doing things right, the alumni community can be a valuable asset in joining a program. If you’re looking to be part of a multi-city network, join a program that has multiple locations. If you’re more interested in having a very tight local community, look for a program that focuses on that.

There are lots of other reasons to learn, but those are the main ones we come across. Also, this post is turning into a novel. The bottom line is, if you have a great teacher, and make sure the program is suited to help you reach your goals, you can’t go wrong.

Enjoy the journey! :)
Share:

Labels

Contact Us

Name

Email *

Message *

Recent Posts

Info