Programming has come to encompass all of society. There is no area of our lives that isn't somehow touched upon by code. In some ways our professio...
For further actions, you may consider blocking this person and/or reporting abuse
Two things, no more:
To be a professional developer, you dont need a certificate from X university, you just need hand-on experience building real stuff... it's not like medicine where you need to be certified since you practice on humans.
It's okay to make faulty apps cuz big companies do that too (like google and facebook)... so don't shout at your friend the next time you use his innovative app that has some bugs.
I disagree that it's okay to make faulty apps. I think this is a terrible trend that software is taking. Stability is faltering significantly. There is a pervasive apathy to quality.
At the root of this problem is consumer concern and education, thus it's hard to say what the long-term fix is.
I understand you... but really sometimes we should accept that the "perfect" solutions are just far far way from the person's current skills.
Suppose your friend is working on a transactional-dependent product, he has a great idea, but he doesn't know about MQs, he has no idea about them, and his app is just getting slower with the larger scaling. Should you shut him down? should you blame him for his "slow" app?
Heck no, we should simply accept the imperfectness cuz when people try to make things perfect, it will take years, and their ideas won't appear into existence.
I know that for many the 1st thing is a reality, but one has to be clear about what exactly do you mean by "professional developer". Yes, what you are saying is absolutely right, in all honesty. You can develop apps and write code professionally without a degree, but there is also a bunch of people who are professional developers in a very specific, high technical field, for which they've spent years doing research or studying the laws of nature, and whose qualification are a requirement for their profession because they, to some extent, describe what the person is able to do. Clearly, there are some exceptions, but the general rule exists.
So, while you don't need a certificate to solve some of the problems in the world, you do need it to solve others, and the line is definitely not drawn between "building real stuff vs. practice on humans".
Probably the clarification needed is that you don't need a coding/programming/developing or similar certificate to code/program/develop, but you do need to have the academic background in the area that you are going to develop to.
Just a few points:
you are spending the least of your time actually coding
writing good code requires a lot of practice
reading code requires a lot more practice
code isn't done, when the problem is solved
sometimes it is more productive to delete lines of code instead of adding
beware of "this is draft code which will be changed later" - later easily becomes "never"
being new to a codebase introduce new paradigms and technologies carefully - perhaps the guy before you did and the guy before that did and that is the reason for the mess looking at you and giving you the urge of "having to clean up"
every line of code has a reason why it is like it is - although the reason was that the one who wrote it, did not knew better at the moment
do not be afraid to google - everybody does; but the experts use smarter queries
every programming language sucks
every programming language is dead - some are dead for decades
do not read »Why I left x for y« posts. They are only prequels to »Why I left y and came back to x - new sides of an old love«
do not read posts about »Why x is faster than y« because most people suck at benchmarking - unless you are Brendan Gregg or read a post from Brendan Gregg about benchmarking
stop writing to-do-list-apps in your sparetime unless you are doing a todo list on all the languages you want to write a todo-list-app in
learn languages you love - you will be good at it!
resist job offers for languages you do not love - it will suck and good payment doesn't help
be lazy - automate the hell out of your workflow. Machines have no bad days.
try to write as less code as possible to make lazy readers happy and bugs having a hard time to hide. Remember: »If debugging is the process of removing bugs, then programming must be the process of putting them in.« Edsger Dijkstra.
Do not outsmart yourself: »Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?« Brian Kernighan
I'm good a benchmarking and profiling. I tell all my interview candidates to stop worrying about optimization. I tell my colleagues they're measuring wrong. It's hard. Sounds like a good chapter on its own.
Ah yes, the love affair with todo lists.
Depending on the language, the JIT (-Compiler) optimizes the code anyway - until it doesn't :D
Yes. I tell people to write decent code - the compiler does the rest.
I'll suggest a couple of soft-ish skills that are poorly taught in my experience:
Business risk is unfortunately overlooked by a lot of developers (and I mean not just coders, but everybody in the company). It creates tension when not everybody is aware of the obstacles.
The most important skill in programming is to learn how to communicate effectively with other people: listening and reading, speaking and writing. Write docs and comments unto people. Share your mistakes. Be compassionate. Those skills are more important than any technical knowledge or expertise.
I agree. You'll be happy to know then that in my "What is programming" outline over half is about non-coding skills. Mostly about communications, working together, organization, prioritization, etc.
See, I knew there was a reason I liked you.
I love how there are so many different core values related to programming extolled here, both holistic and technical. I guess it makes sense, as it would be rubbish if we were all the same eh?
If I could communicate just one thing about programming, it would probably be the importance of perseverance.
Persevering through baffling bugs, through shoddily-run projects, through learning complex new skills, and through the ever-changing landscape of applied technology - that's what I've found serves me best.
Sure there'll still be days - weeks even - when it's too hard, or the project is stressful and everything needed to be delivered yesterday, but most of the time these things are temporary and will pass, but you remain :)
Yes. I suppose it's the reason why I learned meditation and mindfulness. :)
Not a true programmer, but from my experience hacking things together:
Understand part of the process involves playing and experimentation. Solving the root cause of the bug will involve meandering through a bunch of how-to articles, tutorials, and stack overflow.
Quickly learn that 95% of the problems you are facing are not unique, and someone else has already done it (e.g. Google it).
It's relatively easy to come up with a core curriculum for a computer science degree, but much harder to say what "all programmers should know." It's totally possible to have a fulfilling career in a particular area and not know very much about other areas.
I guess I would say, on the more technical side of things, there are two general things that one should strive to improve: 1) Problem solving and 2) judgement.
Problem solving is about finding solutions to problems, whether that's designing a load balancing strategy for a web app, reducing frequency of access to flash memory in an embedded device, or figuring out how to graph some data in excel.
Judgement is about evaluating whether a given solution is a reasonable approach to a problem. Is this code clean and readable? Is this optimization needed? Is this design too complicated?
But how to teach these things? I can't think of anything other than just doing and having good mentors: The more problems one solves, the better. If one has access to mentors who instill good values, that also helps a lot.
I know you're good at finding simplifications to solve problems. Maybe you could write a book of case studies where you were able to simplify a problem relative to whatever solution was previously proposed or considered...
I'm not sure about the "easy to come up with a core curriculum" part. I've unfortunately interviewed a lot of people that came from colleges, of various types, and were unfortunately not introduced to a lot of core concepts.
I don't think a program should focus too much on the soft skills, but they also seem lacking in technical skills. This seems to depend on the school a lot.
Sorry - I meant that listing the subjects to cover is easy, not teaching them effectively. But the big question is, sure, listing a curriculum for cs should be pretty easy, but does everyone who works as a programmer need to know the material that ought to be covered by a cs degree? I think it would be nice if every programmer had a solid knowledge of all these subjects (acquired via a degree or just learned independently), but it's probably not realistic. A lof of people don't get cs degrees, and most of those that do, as you suggested, don't actually have a very strong grasp of the subjects they took...
No, you can be a career coder without being exposed to all of programming. If somebody is happy with that, then fine. Not everybody needs to be everything. But for those that want more, I'm not sure there's a clear path now.
At it core, programming is about managing the
gotostatement, at a higher level it's about function, or a piece of code.At a higher level, treat function at a value that you could return.
That's it all about programming.
I'm only sometimes a programmer and I'd say, be aware of business needs and team needs. Being quick to do exactly what's assigned (and not do whats not assigned) makes you quite a ...commodity. To be stacked in the corner with the printer and some books. IMO to be valuable you must be thoughtful about approaches ("can I understand the business use of this..it feels like a fragile thing you're asking for.."), and respectful of team members (..remind the boss that he's asking you to invade a code space that another dev is working without consulting that person, and you're not comfortable with that). If you're not thoughtful enough but just a coding machine, in the end other (good) team members will distrust you and you'll be pretty lonely at work, others either moved on or considering you a liability--and that includes the perplexed boss who likes how fast you produce but hates how he always needs to make someone do it over again.
I wonder if people think this because the soft skills are what tend to be lacking in programmers. Is it an over-reaction to the current state? Or is it merely a series of stereotypes?
I think a good programmer needs to have a good balance of skills. I'd rather work with somebody who has all-round okay skills than a guy that is a good talker with poor coding skills.
Dear full stack/front end developers,
Learn about accessibility as soon as possible. Accessibility should be integrated throughout your entire development process from concept and design through implementation. Creating inclusive software is your whole team's joint responsibility and often the developer is the last line of defense.
Creating inclusive and accessible user interfaces is your job -- not a stretch goal.
I'd like people to know that not everbody can be or become a software engineer.
I think I know what you mean, but would you care to clarify? I assume you mean in terms of personality, desires, and innate skill alignment.
There are multiple aspects to this.
It's not for everybody. As well as writing, poetry, music, architecture, construction, medicine, law.
You have to put in time and patience, be persistent, curious, driven to be a software engineer. Well that's probably true for any profession if you wanna be good at it. You also have to have a good memory, logical/analytical thinking, attention to details, etc. You also have to work a lot on your own to improve. Day after day after day. So traits, yeah. Mindset.
The 'C++ in 21 days' fallacy. People have this idea that if they go through a book like this, it means they're developers. 21 days is not even enough to go through STL thoroughly. Sure, you'll learn the syntax, but that can be compared to knowing how details of a complicated mechanism look like. It doesn't help with building or understanding the mechanism. People usually don't think they can become doctors after reading a couple of medical books.
The high demand/low supply situation we're in. Even a mediocre developer will be hired for an enormous amount of money. So yeah, why won't I complete a 'crash course in javascript' and go earn some $$$? Sure, it works, today. However, the ability to earn money with writing code doesn't make me a good software engineer. Doesn't make a software engineer at all. Don't know how to name it.
I've seen this a lot. I've seen software engineers that don't understand how a filesystem works, not on a primitve level, or network, or memory, or CPU, you name it. In spite of their programs interact with all of these, constantly. They just don't care. People don't see any problems when deduplicating a list with O(n2) algorithms. It doesn't qualify as engineering in my book.
Then, this beautiful mindset of justifying half-baked products. Even here, there's a comment that says - it's OK because everybody does it. Sure, why not? Let's build a bridge in a hurry, not test it and open it. And there will be followers! Isn't it great that people don't die of software deficiencies (well usually, sometimes they do)?
As a result of all this combined, here's what we have: text editors 1GB in size that can't load 10MB files and fail to switch tabs smoothly; terminal emulators with 500 ms lag as soon as you open 20 tabs; websites with 10s loadtime; and bugs, bugs, inconsistencies, half-bakery everywhere.
I'd like people to not contribute to it. To not make it even worse.
Yes, I agree. This is partly why I want to write a series of books/essays. There's a lot of people that got into programming for a specific job and may want to learn more, but just don't know what the field has in store. I want to give a chance to everybody, regardless of background, to see everything that is programming.
I’m not sure how a book will help them to look around. There’s a ton of information on fundamental stuff that matters, it’s just only a small fraction is interested in it.
I agree there is a ton of information around, but I also think a lot of it is a bit disorganized, or very technology specific.
Less is more
K
One rule to hit estimates.