However, there are a couple of things you need to know when starting in web development.<\/p>\n\n\n\n\n\n\n
Try Usersnap for Product Development<\/h2>Try Usersnap Now<\/a><\/div>\n\n\n\nLearn how to express yourself<\/h2>\n\n\n\n
It came to me a couple of weeks ago while talking with SaaS founders and CTOs<\/a>. Again – the one thing every technology-orientated company keeps telling you: One of the most important skill in web development is communication<\/b>!<\/p>\n\n\n\nWorking as a developer<\/a>, software engineer or no matter how you call it, require strong skills in expressing yourself and building trust. Creating goods which are not really tangible requires you to make your ideas clear and plain.<\/p>\n\n\n\nLearn how to say no<\/h2>\n\n\n\n
Saying \u201cno\u201d sounds pretty harsh. And it\u2019s probably one of the hardest things for us as developers. Saying no to ideas, features or even products. Especially if they are great.<\/p>\n\n\n\n
Nevertheless, we have to learn how to “say no” (even to great ideas) in order to not forget about the bigger picture we aim for.<\/p>\n\n\n\n
\nDo not waste time on “nice ideas”.<\/h3>\n<\/blockquote>\n\n\n\nCode changes & so do you<\/h2>\n\n\n\n
I guess it happens quite a lot. We are completely convinced that the website\/app\/product someone else built lacks some quality. I stumbled upon this conversation<\/a> about how developers think about other developer\u2019s code, and about their own code too \ud83d\ude42<\/p>\n\n\n\n![\"what](\"https:\/\/usersnap.com\/blog\/wp-content\/uploads\/2015\/03\/what-no-one-tells-you-about-web-development.png\")
<\/figure>\n<\/div>\n\n\n<\/p>\n\n\n\n
It\u2019s always easy looking back at someone else\u2019s code. Don\u2019t forget that every one of us evolves and so does our code.<\/p>\n\n\n\n
Create – don\u2019t build<\/h2>\n\n\n\n
A lot of developers – and their environment as well – see themselves as makers or builders. Building things the product managers dreamed up and the designers made esthetically.That\u2019s kind of a narrow perspective since it basically states: quality of developer = quality of code<\/p>\n\n\n\n
I\u2019ve recently read this piece about software engineers<\/a> and I completely agree with the following quote:<\/p>\n\n\n\n\n\u201cSoftware engineers aren\u2019t builders. Software engineers are creators\u201d<\/i><\/h3>\n<\/blockquote>\n\n\n\n
Building means that the instructions are laid out and you work step by step in order built what you\u2019ve designed beforehand.<\/p>\n\n\n\n
Creating is different<\/em>. Creating means starting with a plain page and painting a masterpiece. Developers don\u2019t code<\/a> because someone tells them what & how to do. They create something useful. Something people find useful & use.<\/p>\n\n\n\nDevelopers are part of the creative process.<\/strong><\/p>\n\n\n\nAsk questions. Ask a lot of questions.<\/h2>\n\n\n\n
I\u2019ve experienced a couple of situations where I felt uncomfortable while people were talking about all kind of \u201ccomplex and magical\u201d things and basically everyone was nodding. Later I\u2019ve discovered that most people didn\u2019t had a clue what the person was talking about, but agreed because \u201cit sounded so complex and great\u201d.<\/p>\n\n\n\n
Well, here\u2019s my point: Ask questions<\/strong>. Ask a lot of questions until you get behind \u201cthe magic\u201d. Focus on the common goal and bring everyone up-to-speed. You won\u2019t believe how easy it is to create that situation by simply asking.<\/p>\n\n\n\nShow passion, but don\u2019t show ego.<\/h2>\n\n\n\n
I guess most developers are passionate about the work they do. It\u2019s not only common amongst developers but in other creative industries too.<\/p>\n\n\n\n
And to be honest it\u2019s a scenario which a lot of us aim to achieve. Being passionate about your work is great. However, it can be seen as shellfish from the outside.<\/p>\n\n\n\n
The simplest abstractions are usually best<\/h2>\n\n\n\n
I discovered an interesting Quora thread <\/a>on how to be more productive as a developer. Jonathan Blow\u2019s talk highlights the mind of the programmer as the real time killer. Reducing the complexity of your tasks will also help you to be more productive<\/strong>.<\/p>\n\n\n\nAs he states:<\/p>\n\n\n\n
\n“If you can keep it all in your head, you will be faster. You can\u2019t keep it all in your head if there is this ton of complexity\u201d.<\/h3>\n<\/blockquote>\n\n\n\n
With every new class\/method you add to your code, the complexity will increase exponentially. Keep it simple!<\/p>\n\n\n
Try Usersnap for Product Development<\/h2>Try Usersnap Now<\/a><\/div>\n\n\n\nConsider your code\u2019s future<\/h2>\n\n\n\n
Considering the future of your code is key regarding the sustainability of your work. Maintenance is an important area as well as Nic stated in his post<\/a> too. Not only regarding costs, but also regarding your successors which may follow. Make your code easy to read.<\/strong><\/p>\n\n\n\nAnd as Karan wrote in his essay about \u201cthe 7 rules for writing software that won\u2019t die when you do<\/a>\u201d I\u2019d like to finish with this awesome quote:<\/p>\n\n\n\n\n\u201cLearning to make software is a skill. Anyone can do it. Learning to make good software is an art.\u201d<\/i><\/h3>\n<\/blockquote>\n\n\n\n
Working as a developer<\/a>, software engineer or no matter how you call it, require strong skills in expressing yourself and building trust. Creating goods which are not really tangible requires you to make your ideas clear and plain.<\/p>\n\n\n\n Saying \u201cno\u201d sounds pretty harsh. And it\u2019s probably one of the hardest things for us as developers. Saying no to ideas, features or even products. Especially if they are great.<\/p>\n\n\n\n Nevertheless, we have to learn how to “say no” (even to great ideas) in order to not forget about the bigger picture we aim for.<\/p>\n\n\n\n I guess it happens quite a lot. We are completely convinced that the website\/app\/product someone else built lacks some quality. I stumbled upon this conversation<\/a> about how developers think about other developer\u2019s code, and about their own code too \ud83d\ude42<\/p>\n\n\n <\/p>\n\n\n\n It\u2019s always easy looking back at someone else\u2019s code. Don\u2019t forget that every one of us evolves and so does our code.<\/p>\n\n\n\n A lot of developers – and their environment as well – see themselves as makers or builders. Building things the product managers dreamed up and the designers made esthetically.That\u2019s kind of a narrow perspective since it basically states: quality of developer = quality of code<\/p>\n\n\n\n I\u2019ve recently read this piece about software engineers<\/a> and I completely agree with the following quote:<\/p>\n\n\n\n Building means that the instructions are laid out and you work step by step in order built what you\u2019ve designed beforehand.<\/p>\n\n\n\n Creating is different<\/em>. Creating means starting with a plain page and painting a masterpiece. Developers don\u2019t code<\/a> because someone tells them what & how to do. They create something useful. Something people find useful & use.<\/p>\n\n\n\n Developers are part of the creative process.<\/strong><\/p>\n\n\n\n I\u2019ve experienced a couple of situations where I felt uncomfortable while people were talking about all kind of \u201ccomplex and magical\u201d things and basically everyone was nodding. Later I\u2019ve discovered that most people didn\u2019t had a clue what the person was talking about, but agreed because \u201cit sounded so complex and great\u201d.<\/p>\n\n\n\n Well, here\u2019s my point: Ask questions<\/strong>. Ask a lot of questions until you get behind \u201cthe magic\u201d. Focus on the common goal and bring everyone up-to-speed. You won\u2019t believe how easy it is to create that situation by simply asking.<\/p>\n\n\n\n I guess most developers are passionate about the work they do. It\u2019s not only common amongst developers but in other creative industries too.<\/p>\n\n\n\n And to be honest it\u2019s a scenario which a lot of us aim to achieve. Being passionate about your work is great. However, it can be seen as shellfish from the outside.<\/p>\n\n\n\n I discovered an interesting Quora thread <\/a>on how to be more productive as a developer. Jonathan Blow\u2019s talk highlights the mind of the programmer as the real time killer. Reducing the complexity of your tasks will also help you to be more productive<\/strong>.<\/p>\n\n\n\n As he states:<\/p>\n\n\n\n With every new class\/method you add to your code, the complexity will increase exponentially. Keep it simple!<\/p>\n\n\n Considering the future of your code is key regarding the sustainability of your work. Maintenance is an important area as well as Nic stated in his post<\/a> too. Not only regarding costs, but also regarding your successors which may follow. Make your code easy to read.<\/strong><\/p>\n\n\n\n And as Karan wrote in his essay about \u201cthe 7 rules for writing software that won\u2019t die when you do<\/a>\u201d I\u2019d like to finish with this awesome quote:<\/p>\n\n\n\nLearn how to say no<\/h2>\n\n\n\n
\n
Do not waste time on “nice ideas”.<\/h3>\n<\/blockquote>\n\n\n\n
Code changes & so do you<\/h2>\n\n\n\n
<\/figure>\n<\/div>\n\n\nCreate – don\u2019t build<\/h2>\n\n\n\n
\n
\u201cSoftware engineers aren\u2019t builders. Software engineers are creators\u201d<\/i><\/h3>\n<\/blockquote>\n\n\n\n
Ask questions. Ask a lot of questions.<\/h2>\n\n\n\n
Show passion, but don\u2019t show ego.<\/h2>\n\n\n\n
The simplest abstractions are usually best<\/h2>\n\n\n\n
\n
“If you can keep it all in your head, you will be faster. You can\u2019t keep it all in your head if there is this ton of complexity\u201d.<\/h3>\n<\/blockquote>\n\n\n\n
Try Usersnap for Product Development<\/h2>Try Usersnap Now<\/a><\/div>\n\n\n\n
Consider your code\u2019s future<\/h2>\n\n\n\n
\n
\u201cLearning to make software is a skill. Anyone can do it. Learning to make good software is an art.\u201d<\/i><\/h3>\n<\/blockquote>\n\n\n\n