Use map when you need to transform arrays
let arrayOfNumbers = [1, 2, 3, 4]
let arrayOfString = arrayOfNumbers.map { "\($0)" }
In the context of Array map get an array, applies a transformation function to every element, and returns a new array with the resulting elements. . That's the best use case for map.
Use for loops when there are "side effects"
Without going into details an operation has a side effect if it results in some kind of state changing somewhere, for example changing the value of a variable, writing to disk, or updating the UI. In such case using a for loop is more appropriate.
for number in arrayOfNumbers {
print(number)
}
And what about flatMap?
When you need to transform the contents of an array of arrays, into a linear array use flatMap:
let users: [User] = ...
let allEmails = users.flatMap { $0.emails }
p/s: No difference about performance.
Thanks to this
Tuesday, April 5, 2016
Saturday, April 2, 2016
Build Apps Faster Than Ever Before
Setup an Xcode Derived Data RAM Disk
Would you prefer the time it takes to compile and link your app to be faster or slower?
If you are not using a RAM disk, then you may be choosing the latter answer. If you don’t already know how to set this up, I’ve created an easy to use script written in Swift 2.2. This one may best suit the pros but we can all appreciate a little less waiting for a computer.
As a side note, Swift may not currently be the most efficient way to write scripts, but being able to do it has a special kind of sparkle that lights up when it is done.
Using the script allows the Derived Data setting to stay the same in Xcode but runs out of RAM instead of the disk. It does this by mounting the RAM disk to the same path that is normally disk-based.
This saves wear-and-tear on solid state drives, if you are into that kind of thing. If you happen to be using a spinning disk, it’s way faster than that, too.
I’ve been running Xcode like this for years and over that time all those savings can really add up.
It’s easy to create a launch agent, simply a property list file, that allows having the script run every time your computer starts. I’ve included an example of that in the source code.
I’ve even made sure using this technique works with Instruments because there is a need for Spotlight to find symbol files during profiling and debugging.
The script is contained in an Xcode project. The file
Here is the link to the project.
Original post
Would you prefer the time it takes to compile and link your app to be faster or slower?
If you are not using a RAM disk, then you may be choosing the latter answer. If you don’t already know how to set this up, I’ve created an easy to use script written in Swift 2.2. This one may best suit the pros but we can all appreciate a little less waiting for a computer.
As a side note, Swift may not currently be the most efficient way to write scripts, but being able to do it has a special kind of sparkle that lights up when it is done.
Using the script allows the Derived Data setting to stay the same in Xcode but runs out of RAM instead of the disk. It does this by mounting the RAM disk to the same path that is normally disk-based.
This saves wear-and-tear on solid state drives, if you are into that kind of thing. If you happen to be using a spinning disk, it’s way faster than that, too.
I’ve been running Xcode like this for years and over that time all those savings can really add up.
It’s easy to create a launch agent, simply a property list file, that allows having the script run every time your computer starts. I’ve included an example of that in the source code.
I’ve even made sure using this technique works with Instruments because there is a need for Spotlight to find symbol files during profiling and debugging.
The script is contained in an Xcode project. The file
main.swift can be copied out and renamed to setupXcodeDerivedDataRAMDisk.swift and placed in a bin directory for running from the command-line or a launch agent.Here is the link to the project.
Original post
Monday, March 7, 2016
Sunday, October 11, 2015
The sketchyTech Manifesto
1. Sharing as you learn has value
Aside from the fact that to become fully versed in any technology where the sands are always shifting is a near impossibility, it is true that learning from a learner holds its own value.
Once our learning is complete (or near to complete) all of those daunting documents become less daunting and we forget why we were ever scared by the small things (and what those small things even were). It becomes necessary in the position of accomplished expert, therefore, to imagine ourselves back into the role of learner. The recent learner, meanwhile, has only just been to the place where the learner close behind has just arrived. He or she remembers the path exactly and can guide the fellow learner across the bumps, smoothing the way as they go.
2. Stand up and be corrected
It is important that we blog as we learn. Not only to guide others and as a record for ourselves, but also so that we can be corrected by people another step or more ahead, or on another path altogether. After all we all learn by our mistakes and the humiliations we suffer.
3. It is important to acquire knowledge across a broad range of technologies
Learning about how to script something in JavaScript and then doing the same thing in Objective-C is valuable because we learn new ways to structure and order code. We learn the most useful ways to organise data and carry different ideas across our practice.
This is one example among many of the way in which allowing knowledge to pass across boundaries helps it to grow. There is no end to the combinations that will help you learn.
4. Keep things as short as possible
Specs and documentation are often bloated, disorganised, spread across unlinked areas of a website. Lots is out of date and sometimes deprecated. Examples are often too long and need lengthy unpicking to find the piece of the puzzle you are missing. It is better to have lots of small, short examples that teach single things people will want to know without the surrounding cruft of a make-believe app.
5. Listen to others and be inspired
Your social networks are full of people asking questions. Be inspired by people on twitter, Facebook, LinkedIn, Quora, Coderwall and StackOverflow to answer questions, to go further with ideas than others do. Use the opportunity of a blog to do more, but at the same time value its immediacy and the ability to respond to the needs of others quickly.
6. Don't be put off by people who tell you that you don't know what you're talking about
Your work is of value to those in the same position as you. Your writings are not the final truth, they are a stepping stone to further, more exact knowledge.
One day the people who learnt from you will know more than you, but only because you were one of the people who took the first steps with them.
7. Experiences from different fields add value to this one
ebooks and publishing-related technologies are a hybrid. People with IT degrees are of no more or less value than those with backgrounds in the traditional publishing industry. We need to work towards understanding the worlds of one another in order to progress and make good stuff. We need people who are bridges as well. Between programmers and art, between publishing and electronics, between typography and technology, between authors and the W3C, between indexers and the IDPF, and so on and so on. Don't treat each other like idiots.
http://sketchytech.blogspot.com/p/the-sketchytech-manifesto.html
Aside from the fact that to become fully versed in any technology where the sands are always shifting is a near impossibility, it is true that learning from a learner holds its own value.
Once our learning is complete (or near to complete) all of those daunting documents become less daunting and we forget why we were ever scared by the small things (and what those small things even were). It becomes necessary in the position of accomplished expert, therefore, to imagine ourselves back into the role of learner. The recent learner, meanwhile, has only just been to the place where the learner close behind has just arrived. He or she remembers the path exactly and can guide the fellow learner across the bumps, smoothing the way as they go.
2. Stand up and be corrected
It is important that we blog as we learn. Not only to guide others and as a record for ourselves, but also so that we can be corrected by people another step or more ahead, or on another path altogether. After all we all learn by our mistakes and the humiliations we suffer.
3. It is important to acquire knowledge across a broad range of technologies
Learning about how to script something in JavaScript and then doing the same thing in Objective-C is valuable because we learn new ways to structure and order code. We learn the most useful ways to organise data and carry different ideas across our practice.
This is one example among many of the way in which allowing knowledge to pass across boundaries helps it to grow. There is no end to the combinations that will help you learn.
4. Keep things as short as possible
Specs and documentation are often bloated, disorganised, spread across unlinked areas of a website. Lots is out of date and sometimes deprecated. Examples are often too long and need lengthy unpicking to find the piece of the puzzle you are missing. It is better to have lots of small, short examples that teach single things people will want to know without the surrounding cruft of a make-believe app.
5. Listen to others and be inspired
Your social networks are full of people asking questions. Be inspired by people on twitter, Facebook, LinkedIn, Quora, Coderwall and StackOverflow to answer questions, to go further with ideas than others do. Use the opportunity of a blog to do more, but at the same time value its immediacy and the ability to respond to the needs of others quickly.
6. Don't be put off by people who tell you that you don't know what you're talking about
Your work is of value to those in the same position as you. Your writings are not the final truth, they are a stepping stone to further, more exact knowledge.
One day the people who learnt from you will know more than you, but only because you were one of the people who took the first steps with them.
7. Experiences from different fields add value to this one
ebooks and publishing-related technologies are a hybrid. People with IT degrees are of no more or less value than those with backgrounds in the traditional publishing industry. We need to work towards understanding the worlds of one another in order to progress and make good stuff. We need people who are bridges as well. Between programmers and art, between publishing and electronics, between typography and technology, between authors and the W3C, between indexers and the IDPF, and so on and so on. Don't treat each other like idiots.
http://sketchytech.blogspot.com/p/the-sketchytech-manifesto.html
Saturday, August 8, 2015
9 trở ngại của người Việt Nam khi làm việc nhóm
Nhóm đóng vai trò quan trọng nhằm đảm bảo năng suất và chất lượng
công việc. Trong khủng hoảng, cắt giảm nhân sự trở nên thường xuyên. Cắt
giảm nhân sự bắt buộc các nhân viên phải làm nhiều công việc hơn và đảm
đương nhiều hơn một vị trí. Trong thời hoàng kim nhóm làm việc quan
trọng và trong thời gian khủng hoảng, nhóm làm việc trở thành yếu tố
quyết định để giải bài toán khủng hoảng “ Làm nhiều hơn với nguồn lực ít
hơn”. Khi các nhân viên trong nhóm cộng hưởng tốt, kết quả tạo ra sẽ
vượt trội hơn tổng của toàn bộ cá nhân trong nhóm. Các công ty nước
ngoài và liên doanh tại Việt Nam rất hiểu triết lý đó do vậy các chương
trình đào tạo Team Building được quan tâm và chú ý đặc biệt. Trên thực
tế, các công ty Việt Nam không có ngân quỹ nhiều cho hoạt động đào tạo
cũng có thể định hướng phát triển nhóm hiệu quả thông qua các hoạt động
đào tạo, thay đổi nhận thức của nhân viên. Các chương trình này có thể
tập trung vào một số rào cản làm việc nhóm cố hữu của người Việt Nam như
sau
1. Chứng tỏ cái tôi hay năng lực cá nhân
Các nhân viên Việt Nam khi hoạt động trong nhóm thường hay bày tỏ và tìm cách chứng minh năng lực hoặc cá nhân mình. Nhóm không phải là sân khấu để một ca sỹ hay nhạc công tìm cách thể hiện mình. Một biểu hiện thường thấy của tính cách này đó là hay chỉ trích và phản đối ý kiến các thành viên khác trong nhóm. Tuy nhiên bản thân họ sẽ không có bất kỳ một giải pháp hay sáng kiến nào thậm chí khi họ phê phán và chỉ trích kịch liệt những người khác. Nhóm chỉ có thể sáng chói khi hoàn thành nhiệm vụ được giao. Các thành viên nhóm không thể tự hào về mình trong hoàn cảnh nhóm thất bại.2. Biết nhiều nhưng không biết sâu
Nhóm thể hiện triết lý phụ thuộc lẫn nhau trong môi trường kinh doanh của thế kỷ 21. Công việc đòi hỏi rất nhiều các kỹ năng, kiến thức sâu và hẹp. Năng lực con người là có hạn và tri thức là vô hạn. Mỗi thành viên nhóm cần phải có những chuyên môn đủ sâu để giải quyết các vấn đề yêu cầu. Như vậy, các thành viên sẽ thiếu những kỹ năng khác mà họ có được từ nhóm. Các nhân viên Việt Nam thường không tập trung sâu vào các lĩnh vực. Chính vì như vậy họ thường hay biểu lộ như lý do một về bề rộng của chuyên môn thay vì bề sâu.3. Tiếp cận vấn đề theo triết lý Thua- Thắng
Các nhân viên Việt Nam thường tiếp cận vấn đề theo triết lý thua- thắng khi đòi hỏi quyền lợi cho bản thân cá nhân nhiều hơn trong khi không quan tâm tới quyền lợi của nhóm và các thành viên khác. Triết lý thắng – thắng không được áp dụng trong suy nghĩ và hành xử thường ngày để nhằm làm to thêm chiếc bánh của toàn nhóm. Thông qua cơ hội đó mỗi cá nhân sẽ có kết quả nhiều hơn.4. Quên đi đại cục và tập trung vào tiểu tiết
Suy nghĩ thua-thắng là tác động tạo ra điểm yếu thứ tư khi các nhân viên Việt Nam tập trung vào tiểu tiết thay vì đại cục. Ngoài ra lý do một cũng là yếu tố tác động quan trọng cho lý do này. Thay vì tìm các tiếp cận hệ thống giải quyết vấn đề, các nhóm việt nam sa đà vào các tác vụ giải quyết tiểu tiết hàng ngày.5. Suy nghĩ cảm tính không dựa trên dữ kiện và tư duy logic
Các nhân viên Việt Nam thường tranh luận ít dựa trên dữ kiện và tư duy logic. Các vấn đề thực tiễn cần được nghiên cứu, đánh giá một cách khách quan. Ngoài ra yếu tố kinh nghiệm cũng là một trở ngại trong quá trình làm việc nhóm.6. Văn hóa làng xã – nể nang không phê bình khuyết điểm
Tâm lý ngại va chạm thủ thế khiến cho các nhân viên Việt Nam không kiên quyết phê bình và đấu tranh khi các thành viên nhóm không hiệu quả. Bản thân cá nhân có thể được lợi nhưng toàn bộ nhóm sẽ không đạt kết quả tốt. Suy nghĩ làm việc cho qua chuyện cũng là một yếu tố làm trầm trọng thêm khuyết điểm này.7. Không tách biệt vấn đề và con người
Khi mâu thuẫn xẩy ra, các nhân viên Việt Nam thường không tách bạch con người và vấn đề. Thay vì bàn luận vấn đề, các nhân viên Việt Nam thường chỉ trích cá nhân người có ý kiến đi ngược với mình. Thói quen này có thể là nguyên nhân rất trầm trọng làm giảm tính hiệu quả của nhóm. Tác giả đã gặp trên thực tế một việt kiều tên D khá nổi tiếng trong giới công nghệ thông tin tại Việt Nam và được giáo dục đào tạo trong môi trường phương Tây. Khi tranh luận với những ý kiến trái chiều ông ta thường hay sử dụng những từ ngữ không lịch sự đả phá những cá nhân có suy nghĩ trái chiều mình. Qua ví dụ đó để thấy rằng những gì thuộc bản chất rất khó thay đổi trong cuộc sống. Sự tôn trọng là nền tảng căn bản của nhóm hiệu quả và là sự khởi đầu của những tranh luận tích cực.8. Không tuân thủ quy trình và các luật lệ của nhóm
Khi gia nhập nhóm, các thành viên cần hạ bản thân cá nhân thấp hơn nhóm làm việc. Các nhân viên Việt Nam thường không tôn trọng qui trình và các luật lệ. Một ví dụ đơn giản khi họ thường không giao nộp các phần việc làm đúng thời gian qui định. Hiện tượng này làm giảm hiệu suất của toàn nhóm.9. Giao tiếp không hiệu quả
Nhóm hiệu quả bắt buộc các thành viên giao tiếp hiệu quả trong quá trình làm việc. Các thói quen xấu trong giao tiếp như nói nhiều hơn nghe, không truyền tải thông tin đầy đủ, luôn luôn trả lời hiểu mặc dù chưa hiểu hết v/v thường xuất hiện trong các nhóm làm việc tại Việt Nam.(Theo Quanlycaptrung.vn)
Wednesday, July 8, 2015
Rebuild icon cache on windows
1. Close all folder windows that are currently open.
2. Launch Task Manager using the CTRL+SHIFT+ESC key sequence, or by running taskmgr.exe.
3. In the Process tab, right-click on the Explorer.exe process and select End Process.
4. Click the End process button when asked for confirmation.
5. From the File menu of Task Manager, select New Task (Run…)
6. Type CMD.EXE, and click OK
7. In the Command Prompt window, type the commands one by one and press ENTER after each command:
CD /d %userprofile%\AppData\Local
DEL IconCache.db /a
EXIT
8. In Task Manager, click File, select New Task (Run…)
9. Type EXPLORER.EXE, and click OK.
Friday, July 3, 2015
The Role of a Senior Developer
We work in a strange industry. There is a much
higher need for developers than can be satisfied by new developers
coming into the field. This is a problem that has existed for years, and
it is getting worse as time goes on.
We have a serious shortage of talent to meet the demand, but our industry is really quite young . Most software projects fail. Nearly all of them come in over budget. The best guidance we have on this subject from thought leaders boils down to “These are some common ways we solve these problems, but our solutions frequently don’t work, so the only thing you can really do is try it out and see if it works for you”.
The reality we live in is that “Senior Developer” means a person who has been slinging code for more than 3 years. These people are put into leadership positions, and typically things play out as you would expect — quite badly.
This is my take on the terms we use in the industry. Really, putting people into 3 buckets is a huge over-simplification of the nuance, knowledge, and experience of progressing through this profession, but it is what it is. If we are going to classify people in this way, then we need to take time in the industry off the table. A person with 10 years experience is quite different than someone who has experienced the same year 10 times.
This is the life of the junior developer. You are fresh out of school, and think you know everything. Suddenly, you are faced with the fact that what you learned about in school was actually quite poor preparation for the types of problems you are encountering. Things are more messy. Less theoretically pure. You are existing in a realm of compromises, and can never make assumptions about anything.
Dealing with this is really all you can focus on, and it is what you really should be trying your best to learn. Junior developers need a lot of direction, supervision, and mentoring because of this, or they can stay in this place for a very, very long time (I recently encountered a fellow who had been building software for almost a decade who I would say is still a junior). You can say that this period is really about acquisition of tactical, day to day techniques.
A junior developer is code focused, not development focused, and doesn’t understand the distinction. When a programmer talks about how they “would love coding more, if it weren’t for all the users”, I assume I am talking to a junior developer.
An intermediate is someone who is looking for answers on how to build things The Right Way, and finding them through experimentation, literature, and discussion with other programmers. This level is really about learning the theory of building of software, rather than the theory of building code (which is learned in school).
Systems built by unsupervised intermediate developers are going to fail for completely different reasons than systems built by juniors. A junior will build a big pile of algorithms that sort of work. A good intermediate will build pages out of “Design Patterns” and “Domain Driven Design”. While those are great books for learning how to build large OO systems, direct application of this sort of theory results in over engineered systems that are flexible in ways that don’t matter, and inflexible in ones that do matter.
You can trust an intermediate to build systems that will work for far longer than a junior, but will lead to a different sort of disaster down the road. The sad fact is that the vast majority of not only senior developers, but team leaders are in fact, intermediate devs. Most do not realize this, and have the best intentions, but have simply never worked with anyone who is at a higher level.
Intermediates are quite aware of their role in their organization, and the value they bring. A good intermediate understands how using code to solve a problem is the means to an end, not the end in and of itself. However, they are still in love with ivory tower design, and are still on a quest for “The Right Way” to build software.
A senior developer stops classifying developers based on their knowledge, and instead understands that there is a spectrum of strengths and weaknesses. They are more intimately aware of their own strengths and weaknesses than anyone else could ever be, and strive to play to their own strengths whenever possible.
A senior developer thinks in terms of “context” when applying theory. They understand that there is no “Right Way” to build software, and that the only way to build good software is by adapting theory to fit the needs of the client, codebase, team, tools, and organization.
A senior developer understands that everything in our field involves tradeoff, and will look for what that is for design patterns, libraries, frameworks, and processes.
A senior developer thinks of more than just themselves. They are aware of how their organization and their clients work, what their values are, and what is both important and not important for success. When a ball is dropped, a senior developer will do what they can to pick it up. The phrase “this is not my job” is never, ever said in those situations.
A senior developer will understand that this job is to provide solutions to problems, not write code. Because of that, a senior developer will always think of what they are doing in terms of how much value it brings to their organization and their clients vs how much effort they are putting in.
While an intermediate will plow through days of boring work, a senior developer will take a step back and question what is breaking down to cause all that boring work to begin with. They will evaluate the cost of fixing root problems, and either fix them directly, or put things in motion so they will be fixed eventually.
A senior developer understands that you cannot do everything yourself, and that their primary role is to help their team get better, in many of the same ways they themselves strive for personal improvement.
A senior developer understands that leadership is not about power, it is about empowerment. It is not about direction, it is about serving.
More than that, our industry values wicked smart young guys fresh out of university. Those people are valuable, and necessary, but so are people who have 15-20 years experience in the field. We need to stop hiring according to stereotypes, and start really thinking of team and organizational talent composition. If everyone on your team thinks the same, you are doing your product and your organization a disservice.
@Source
We have a serious shortage of talent to meet the demand, but our industry is really quite young . Most software projects fail. Nearly all of them come in over budget. The best guidance we have on this subject from thought leaders boils down to “These are some common ways we solve these problems, but our solutions frequently don’t work, so the only thing you can really do is try it out and see if it works for you”.
The reality we live in is that “Senior Developer” means a person who has been slinging code for more than 3 years. These people are put into leadership positions, and typically things play out as you would expect — quite badly.
This is my take on the terms we use in the industry. Really, putting people into 3 buckets is a huge over-simplification of the nuance, knowledge, and experience of progressing through this profession, but it is what it is. If we are going to classify people in this way, then we need to take time in the industry off the table. A person with 10 years experience is quite different than someone who has experienced the same year 10 times.
The stages of software developer growth
As programmers, we live in a world of complex systems and variables. It is incredibly challenging to simply execute a well defined and focused task, especially if you are not terribly experienced with the tools at your disposal, or the codebase you are working on.This is the life of the junior developer. You are fresh out of school, and think you know everything. Suddenly, you are faced with the fact that what you learned about in school was actually quite poor preparation for the types of problems you are encountering. Things are more messy. Less theoretically pure. You are existing in a realm of compromises, and can never make assumptions about anything.
Dealing with this is really all you can focus on, and it is what you really should be trying your best to learn. Junior developers need a lot of direction, supervision, and mentoring because of this, or they can stay in this place for a very, very long time (I recently encountered a fellow who had been building software for almost a decade who I would say is still a junior). You can say that this period is really about acquisition of tactical, day to day techniques.
A junior developer is code focused, not development focused, and doesn’t understand the distinction. When a programmer talks about how they “would love coding more, if it weren’t for all the users”, I assume I am talking to a junior developer.
A good junior developer can be given a known task, and be expected to execute it quickly, and well.
An intermediate developer is one who begins to see patterns in failure (usually their own failure), and recognize that it takes a lot more than banging out focused tasks to actually build something that works, and won’t completely fall over the first time someone needs to change it. They have also gone through the unique experience of looking at something they were proud of writing a year ago, and realizing it was actually pure garbage.An intermediate is someone who is looking for answers on how to build things The Right Way, and finding them through experimentation, literature, and discussion with other programmers. This level is really about learning the theory of building of software, rather than the theory of building code (which is learned in school).
Systems built by unsupervised intermediate developers are going to fail for completely different reasons than systems built by juniors. A junior will build a big pile of algorithms that sort of work. A good intermediate will build pages out of “Design Patterns” and “Domain Driven Design”. While those are great books for learning how to build large OO systems, direct application of this sort of theory results in over engineered systems that are flexible in ways that don’t matter, and inflexible in ones that do matter.
You can trust an intermediate to build systems that will work for far longer than a junior, but will lead to a different sort of disaster down the road. The sad fact is that the vast majority of not only senior developers, but team leaders are in fact, intermediate devs. Most do not realize this, and have the best intentions, but have simply never worked with anyone who is at a higher level.
Intermediates are quite aware of their role in their organization, and the value they bring. A good intermediate understands how using code to solve a problem is the means to an end, not the end in and of itself. However, they are still in love with ivory tower design, and are still on a quest for “The Right Way” to build software.
A good intermediate developer needs less supervision. They can be trusted to raise issues of code design, and play a valuable role in design discussions. They are also the “workhorses” of the dev team. However, further mentoring and higher level supervision is still vital.
A senior developer is intimately familiar with their own failure. They have written code both under, and over designed, and have seen both fail. They are reflective about the things that they do, evaluating their successes and failures when approaching problems with intellectual honesty. A senior developer has fallen out of love of the complexity which dominates the intermediate, and is obsessed with simplicity.A senior developer stops classifying developers based on their knowledge, and instead understands that there is a spectrum of strengths and weaknesses. They are more intimately aware of their own strengths and weaknesses than anyone else could ever be, and strive to play to their own strengths whenever possible.
A senior developer thinks in terms of “context” when applying theory. They understand that there is no “Right Way” to build software, and that the only way to build good software is by adapting theory to fit the needs of the client, codebase, team, tools, and organization.
A senior developer understands that everything in our field involves tradeoff, and will look for what that is for design patterns, libraries, frameworks, and processes.
A senior developer thinks of more than just themselves. They are aware of how their organization and their clients work, what their values are, and what is both important and not important for success. When a ball is dropped, a senior developer will do what they can to pick it up. The phrase “this is not my job” is never, ever said in those situations.
A senior developer will understand that this job is to provide solutions to problems, not write code. Because of that, a senior developer will always think of what they are doing in terms of how much value it brings to their organization and their clients vs how much effort they are putting in.
While an intermediate will plow through days of boring work, a senior developer will take a step back and question what is breaking down to cause all that boring work to begin with. They will evaluate the cost of fixing root problems, and either fix them directly, or put things in motion so they will be fixed eventually.
A senior developer understands that you cannot do everything yourself, and that their primary role is to help their team get better, in many of the same ways they themselves strive for personal improvement.
A senior developer understands that leadership is not about power, it is about empowerment. It is not about direction, it is about serving.
If you do not have at least one senior developer in a leadership role on your team, your project is doomed to fail. A team of great intermediates will get you very far, but the days of the software you are building are numbered, and the end result is either closing shop, or costly / risky rewrites. A senior developer is the only person fully qualified to choose technology and platforms, so not having one from day one will hurt you.
This is a giant over-simplification
The reality is nobody fits into these buckets perfectly. I am just tired of the “years of experience” based classification. Years of experience tells you something, but is almost pointless information without a lot more context.More than that, our industry values wicked smart young guys fresh out of university. Those people are valuable, and necessary, but so are people who have 15-20 years experience in the field. We need to stop hiring according to stereotypes, and start really thinking of team and organizational talent composition. If everyone on your team thinks the same, you are doing your product and your organization a disservice.
@Source
Subscribe to:
Posts (Atom)